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ELECTRONIC FACTORING 



Background of the Invention 

Field of the Invention 
5 . The invention relates to the field of electronic commerce. 

Description of the Related Art 

Factoring includes buying and selling accounts receivable and credit insuring. Accounts 
receivable are purchased based upon the assumption that the accounts receivable are valid and 
collectable. Accounts receivable are sold in order to quickly obtain cash for cash flow purposes, 

10 rather than to retain them as receivable. Accounts receivable are also frequently used as an asset 
upon which to borrow money, in order to finance other unrelated transactions. Credit insuring 
occurs when an entity insures payment of an account receivable for a vendor, so that if the buyer 
does not pay, the insurer will. With the recent rapid growth of information applications on the 
Internet, computer networks have the potential to establish a new kind of open market place for 

15 goods and services. Buyers and sellers increasingly want to use the Internet to conduct their 
business electronically. This new method of doing business is referred to as electronic commerce, 
or "e-commerce." 

The timely and costly process of processing paper requests for transactions such as the 
buying and selling of accounts receivable, as well as goods and services, plagues business 

20 transactions. Furthermore, buyers and sellers must expend significant resources to make 
appropriate credit decisions regarding a transaction. In procurement transactions, it is customary 
for the transaction to involve some form of credit, such as "open account trade credit," provided by 
the seller generally at no charge to the buyer but for a set period of time, normally thirty days. 
Buyers generally do not explicitly pay for the receipt of open account trade credit, and consider 

25 this free credit part of the established buyer/seller relationship. Credit cards are also available for 
relatively small purchases and operate by having a fmancial institution issue the credit card, and a 
vendor bank provide the cardholder with a revolving line of credit that can be used to buy goods 
from sellers who accept the credit card. This allows the cardholder to pay for credit card purchases 
over a period of time at an interest rate set by the vendor bank. 

30 Other types of credit devices are travel and entertainment cards, which unlike credit cards, 

are considered to be open-ended credit with payment in full due at the time of billing, no extension 
of revolving credit to the buyer is provided by use of these cards, or cardholder. Credit, travel and 
entertainment cards provide a uniform level of risk assessment to the seller and the seller pays a 
pre-determined interchange fee regardless of the actual credit risk presented by the buyer. 
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Commercial transaction are evolving to include electronic communication of financial 
transactions. Advances in computer networks and communication systems now apply to 
processing purchase and credit transactions. An important application of new computer 
technology is electronic commerce, which includes using electronic networks as a marketplace for 
S business and consumer transactions. Electronic commerce services can include electronic 
brokerages, distributorships or clearinghouses that facilitate trade with electronic interchange 
media, such as public networks, for example the Internet, or proprietary access networks. 

Electronic commerce, however, does not currently ofTer financial services to sellers, such 
as payment and credit assessments of buyers, electronic factoring and credit insuring of 

10 transactions. This need is usually fulfilled by relying on traditional techniques of credit analysis 
and payment before a transaction can be completed. 

Various patents discuss methods of performing e-commerce wherein buyers and sellers are 
connected, but none address the issue of electronic factoring and credit insurance. U.S. Patent No. 
4,992,940 to Dworkin, entitled "System and Method for Automated Selection of Equipment for 

IS Purchase Through Input of User Desired Specifications," discloses an automated system that 
assists the user in locating and purchasing goods and services sold by a variety of vendors. U.S. 
Patent No. 5,732,400, to Mandler, et al., entitled "System and Method for a Risk-Based Purchase 
of Goods," discloses a financial clearinghouse for receiving requests for goods or services from a 
buyer and making a real-time determination of a risk classification of the buyer using an online 

20 repository of credit information. U.S. Patent No. 5,757,9 1 7, to Rose, et al., entitled "Computerized 
Payment System for Purchasing Goods and Services on the Internet," discloses a computerized 
payment system that prequalifies and pays a buyer's order through a third party, but is not a 
guarantee-of-payment mechanism. U.S. Patent No. 5,822,737, to Ogram, entitled "Financial 
Transaction System," discloses an automated payment system allowing a consumer to purchase 

25 goods or services over the Internet with a credit card that is verified before making the payment. 
U.S. Patent No. 5,802,497, to Manasse, entitled "Method and Apparatus for Conducting 
Computerized Commerce," discloses the use of a broker, broker scrip, vendor scrip, and currency 
to sell parts and services and deliver to the consumer. U.S. Patent No. 5,745,886 to Rosen, entitled 
"Trusted Agents for Open Distribution of Electronic Money," discloses using a customer trusted 

30 agent and vendor trusted agent and establishing a crypto-graphically secure session, and to provide 
electronic money purchase or sale information and an account credential to the vendor trusted 
agent. U.S. Patent No. 5,557,518, also to Rosen, entitled "Trusted Agents for Open Electronic 
Commerce," also discloses the use of trusted agents, establishing a crypto-graphically secure 
session and electronically transferring funds in purchasing merchandise. U.S. Patent No. 

35 5,717,923, to Dedrick, entitled "Method and Apparatus for Dynamically Customizing Electronic 
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Information to Individual End Users," discloses maintaining a personal profile database to store 
consumer information and a consent adapter to compare electronic information received by a client 
system to consumer information in the personal profile database. 

U.S. Patent No. 5,717,989, to Tozzoli, et a!., entitled "Full Service Trade System," 
5 discloses storing criteria specified by a funder relative to trade transactions for buyers and sellers 
and comparing the criteria with a proposed purchase order in order to determine whether the 
system can generate a payment guarantee on behalf of the funder for the buyer to the seller. U.S. 
Patent No. 5,826,241 to Stein, et a!., entitled "Computerized System for Making Payments and 
Authenticating Transactions Over the Internet," discloses a payment system that provides 

10 cardholder accounts for first and second Internet users and making queries to the first user on 
whether to proceed with payment to the second user. U.S. Patent No. 5,842,178, to Giovannoli, 
entitled "Computerized Quotation System and Method," discloses a computer-based 
communications network of members for processing requests for quotes for goods and services, as 
well as storage containing the identification of the members and means for transmitting and 

15 broadcasting requests for quotes. U.S. Patent No. 5,694,551, to Doyle et al., entitled "Computer 
Integration Network for Channeling Customer Orders Through a Centralized Computer to Various 
Suppliers," discloses an electronic requisitioning system that channels customer orders to internal 
suppliers and outside vendors, and processes invoices. U.S. Patent No. 5,671,280, to Rosen, 
entitled "System and Method for Commercial Payments Using Trusted Agents," discloses a system 

20 for electronic payment using a customer trusted agent and a vendor trusted agent. U.S. Patent No. 
5,664,1 15, to Fraser, entitle d"lnteractive Computer System to Match Buyers and Sellers of Real 
Estate, Businesses and Other Property Using the Internet," discloses automatically connecting 
sellers of property with potential buyers, preferably over the Internet, wherein the host system 
stores records regarding the properties and can be searched by potential buyers, and the system 

25 permits evaluation of potential buyers to screen them. 

Various articles have been written which disclose forms of electronic payment methods, 
but these methodologies only relate to moving money around, from one account to another, 
electronically and do not address the need in the marketplace for electronic factoring. 

Summary of the invention 

30 The invention comprises a method and system for electronic factoring. The inventive 

system overcomes all of the limitations of the prior art and addresses the need for an electronic 
commerce version for factoring. The system enables buyers to purchase goods from vendors with 
a third party guarantee to the vendor via electronic factoring that guarantees the payment. By 
using the system, electronic factoring, including credit insurance, is performed in an efficient 
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manner. The invention enables buyers to obtain goods and services immediately without having 
to pay for them at the time of the transaction. 

The invention also comprises a credit database set up for all users that assigns a credit 
limit to the customers for credit as well as a credit instrument for guarantee of payment to vendors. 
S Payment is guaranteed through a banking partner, the guaranteeing financial institution, who 
guarantees all receivables that are created through the sales on the platform (entitled 'TrofitScape" 
in the Figures) to ensure payment and security of the transaction. The system tracks and maintains 
a database that details credit dollar amounts available and account activity for each user. The 
invention defines a credit-worthy marketplace that enables users, who become members, to 

10 purchase goods and services on credit based on their respective fmancial positions which have 
been evaluated by the guaranteeing financial institution. 

In one embodiment, the method comprises the steps of providing an electronic platform for 
guaranteeing payment of receivables; inputting information from users into a profile database upon 
the electronic platform; assigning buyers a credit limit; and guaranteeing payment to vendors for 

15 users who purchase from the vendor. Additionally, the method comprises linking at least two 
users, the users being either buyers, vendors, international licensees, or financial institutions for 
guaranteeing payment via the platform. Guaranteeing payment to vendors preferably comprises 
aligning the platform with a guaranteeing fmancial institution. Aligning the platform with a 
guaranteeing financial institution preferably comprises aligning the platform with that institution in 

20 order to perform a factoring-type such as credit insuring, full-factoring, or lending. The electronic 
factoring method can further comprise the steps of producing a symbol to represent each user's 
profile and exchanging information between users via the symbol on the electronic platform. 
Guaranteeing payment to vendors can comprise electronically sending the vendor the user's 
symbol in order to show the vendor that payment is guaranteed by the platform. The method can 

2S further comprise the steps of electronically sending the user's symbol to the guaranteeing financial 
institution and sending a guarantee of compensation from the guaranteeing financial institution to 
the vendor. Guaranteeing payment to vendors can comprise the steps of issuing each user an 
identifying card showing membership on the platform; purchasing from the vendor with the 
identifying card; and accessing the user's credit availability via the platform with the identifying 

30 card. 

Providing an electronic platform preferably comprises providing an Internet web site 
having the platform for users to access, and optionally comprises the step of providing Internet 
web site links for users to access other users' web sites. The step of inputting information from 
users into a profile database preferably comprises the steps of inputting data such as name, address, 
35 contact information, primary industry, credit insured amount, payment history, credit usage, target 
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marketplace, products offered, services offered, inventory, buying trend data, and Internet usage 
data. 

The electronic factoring method further can comprise the steps of verifying a user as a 
member of the platform and purchasing from the vendor. Purchasing from the vendor can 
3 comprise first searching the profile database with a search engine, from the vendor preferably 
comprises purchasing from the vendor with a line of credit within the credit limit established by 
the profile database. 

Guaranteeing payment to vendors can comprise the steps of reassigning the receivable to 
the guaranteeing fmancial institution; making payment to the platform; and forwarding payment 

10 from the platform to the vendor. Guaranteeing payment to vendors can alternatively comprise 
reassigning the receivable to the guaranteeing financial institution; making payment to the 
guaranteeing financial institution; and forwarding payment from the guaranteeing financial 
institution to the vendor. In yet another embodiment, guaranteeing payment to vendors comprises 
accessing the platform directly by the vendor for verification of credit availability and forwarding 

IS payment to the vendor upon accessing the guaranteeing financial institution directly by the vendor 
for verification of credit availability and forwarding payment to the vendor upon verification. In 
still another embodiment, guaranteeing payment to vendors comprises accessing the guaranteeing 
financial institution directly by the vendor for verification of credit availability and forwarding 
payment to the vendor upon verification. Still another embodiment of guaranteeing payment to 

20 vendors comprises accessing the platform for verification of credit availability; paying the 
guaranteeing financial institution for purchases; and forwarding payment from the guaranteeing 
financial institution to the platform and vendor bank so that the vendor bank can credit the vendor. 

The electronic factoring method also can comprise the steps of maintaining user credit 
records on the platform and periodically reviewing credit records by the financial institution for 

25 buyer credit availability. Linking at least two users can comprise the steps of creating offers by the 
vendor; sending the offers to an offer database on the platform for storage; comparing the offer 
database with the user profiles in the profile database; creating a list of matching offers and user 
profiles; and offering users those offers that match the user's profile upon log-in. 

In one embodiment, the invention also comprises a method of electronic factoring 

30 comprising the steps of assigning buyers a credit limit upon a guaranteeing platform; verifying the 
buyer's identification, as a member of the guaranteeing platform; verifying the buyer's credit 
amount when the buyer attempts to make a purchase; subtracting the purchase amount from the 
buyer's available credit limit upon making a verified purchase; notifying the vendor of the 
purchase order; reassigning the receivable to a guaranteeing financial institution via the 

35 guaranteeing platform; billing the buyer for the purchase order; and forwarding payment to the 
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vendor. Forwarding payment to the vendor optionally comprises forwarding payment to the 
vendor from either the buyer, the guaranteeing fmancial institution, or the guaranteeing platform. 

In one embodiment, the invention also comprises an electronic factoring system for 
guaranteeing payment.of receivables and comprises an electronic platform; a profile database upon 
5 the electronic platform for inputting information from users; means for assigning buyers a credit 
limit; and means for guaranteeing payment to vendors for users who purchase from the vendor. 
The electronic factoring system can additionally comprise means for linking at least two users 
wherein the users consist of buyers, vendors, international licensees, and Financial institutions for 
guaranteeing payment via the platform. Means for guaranteeing payment to vendors may comprise 

10 means for aligning the platform with a guaranteeing financial institution, and wherein said means 
for aligning the platform with a guaranteeing financial institution comprises aligning with a 
guaranteeing financial institution so that that institution can perform factoring such as credit 
insuring, full-factoring, or lending. The electronic system can further comprise means for 
producing a symbol to represent each user's profile, and means for exchanging information 

15 between users via the symbol on the electronic platform. Means for guaranteeing payment to 
vendors can comprise means for electronically sending the vendor the user's symbol in order to 
show the vendor that payment is guaranteed by the platform. The system can comprise means for 
electronically sending the user's symbol to the guaranteeing financial institution and means for 
sending a guarantee of compensation from the guaranteeing financial institution to the vendor. 

20 Means for guaranteeing payment to vendors can alternatively comprise an identifying card issued 
to each user showing membership on the platform; means for purchasing from the vendor with the 
identifying card, and means for accessing the user's credit availability via the platform with the 
identifying card. 

The electronic platform of the electronic factoring system may comprise an Internet web 
25 site having the platform available for users to access. The Internet web site can further comprise 
links for users to access other users' web sites. The profile database of the electronic factoring 
system may comprise a profile database for inputting data from users. This data can consist of any 
of the following: name, address, contact information, primary industry, credit insured amount, 
payment history, credit usage, target marketplace, products offered, services offered, inventory, 
30 buying trend data, and Internet usage data. 

The electronic factoring system can further comprise means for verifying a user as a 
member of the platform and means for purchasing from the vendor. Means for purchasing from 
the vendor can comprise means for first searching the profile database with a search engine. 
Means for purchasing from the vendor preferably comprises means for purchasing from the vendor 
35 with a line of credit within the credit limit established by the profile database. 
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Means for guaranteeing payment to vendors can comprise means for reassigning the 
receivable to the guaranteeing financial institution; means for making payment to the platform; and 
means for forwarding payment from the platform to the vendor. Alternatively, means for 
guaranteeing payment to vendors comprises means for reassigning the receivable to the 
S guaranteeing financial institution; means for making payment to the guaranteeing flnancial 
institution; and means for forwarding payment from the guaranteeing financial institution to the 
vendor. In still another embodiment, means for guaranteeing payment to vendor comprises means 
for accessing the platform directly by the vendor for verification of credit availability and means 
for forwarding payment to the vendor upon verification. In still another embodiment, the means 

10 for guaranteeing payment to vendors comprises means for accessing the guaranteeing financial 
institution directly by the vendor for verification of credit availability and means for forwarding 
payment to the vendor upon verification. In yet another embodiment, the means for guaranteeing 
payment to vendors comprises means for accessing the platform for verification of credit 
availability; means for paying the guaranteeing financial institution for purchase; and means for 

1 5 forwarding payment from the guaranteeing financial institution to the platform and vendor bank so 
that the vendor bank can credit the vendor. 

The electronic factoring system can further comprise means for maintaining user credit 
records on the platform and means for periodically reviewing credit records by the financial 
institution for buyer credit availability. Means for linking at least two users can comprise means 

20 for creating offers by the vendor; means for sending the offers to an offer database on the platform 
for storage; means for comparing the offer database with the user profiles in the profile database; 
means for creating a list of matching offers and user profiles; and means for offering users those 
offers that match the user's profile upon login. 

The invention also comprises an electronic factoring system for guaranteeing payment of 

25 receivables comprising means for assigning buyers a credit limit upon a guaranteeing platform; 
means for verifying the buyer's identification as a member of the guaranteeing platform; means for 
verifying the buyer's credit amount when the buyer attempts to make a purchase; means for 
subtracting the purchase amount from the buyer's available credit limit upon making a verified 
purchase; means for notifying the vendor of the purchase order; means for reassigning the 

30 receivable to a guaranteeing financial institution via the guaranteeing platform; means for billing 
the buyer for the purchase order; and means for forwarding payment to the vendor. Means for 
forwarding payment to the vendor can comprise means for forwarding payment to the vendor from 
either the buyer, the guaranteeing financial institution, or the guaranteeing platform. 
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One aspect of the invention can provide unique profiled information that is delivered 
through an electronic system using software agents that enable credit and/or a guarantee of 
compensation to vendors for buyers. 

Another aspect of the invention can include a unique database profile which is created 
5 incorporating specific sales and product information detailing what each user has to sell, terms, 
company history, unique product information, and the category of transaction, be it either a retail 
or wholesale target market. 

Another aspect of the invention can provide unique profiled information and open access 
to both buyers and vendors to find information and make purchases guaranteed for payment. 
10 Yet another aspect of the invention can enable users to fmd unique information that 

matches their targeted request and enables them to purchase and consummate transactions 
electronically. 

Yet another aspect of the invention comprises amethod of conducting electronic 
commerce, the method comprising: receiving an electronic authorization request from a vendor for 

15 a payment guarantee, wherein the authorization request identifies a transaction amount between the 
vendor and a buyer; and electronically transmitting to the vendor a guarantee of payment for the 
transaction amount, wherein the guarantee is conditional to the occurrence of one or more events. 
. One of the events may be the receipt of an invoice from the vendor. A transaction fee may be 
charged regardless of the occurrence of the conditions. The transaction fee can be based at least in 

20 part upon either the transaction fee or a payment due date. The method may also comprise: 
receiving an invoice from the seller, wherein the invoice identifies an actual transaction amount of 
a transaction between the buyer and the seller; storing the actual transaction amount in a database; 
and transmitting the invoice to a guarantor. The method may also comprise gauranteeing payment 
based at least in part upon a credit limit of the buyer. The method may also comprise receiving an 

2S invoice from the seller, wherein the invoice identifies a payment due date; and determining, based 
at least in part upon the due date, a fee that is due by the seller. The method may also comprise 
receiving payment from the buyer; and sending payment to the vendor subsequent to subtracting 
the determined fee. Gauranteeing payment may comprise insuring payment by the seller or 
purchasing a receivable from the vendor. 

30 Another aspect of the invention comprises a system for conducting electronic commerce, 

the system comprising: means for receiving an electronic authorization request from a vendor for a 
payment guarantee, wherein the authorization request identifies a transaction amount between the 
vendor and a buyer; and means for electronically transmitting to the vendor a guarantee of payment 
for the transaction amount, wherein the guarantee is conditional to the occurrence of one or more 

35 events. 
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Brief Description of the Drawings 
The accompanying drawings, which are incorporated into and form a part of the 
specification, illustrate several embodiments of the invention and, together with the description, 
serve to explain the principles of the invention. The drawings are only for the purpose of 
3 illustrating a preferred embodiment of the invention and are not to be construed as limiting the 
invention. In the drawings: 

Fig. lA is a block diagram of a first embodiment of the invention showing the flow of 
purchase and fulfillment between buyer and vendor using the electronic commerce web site 
platform of the invention; 

10 Fig. IB is a block diagram of a second embodiment of the invention showing the fiow of 

purchase and fulfillment between buyer and vendor using the electronic commerce web site 
platform; 

Fig. 1C is a block diagram of a third embodiment of the invention showing the flow of 
purchase and fulfillment between buyer and vendor using the electronic commerce web site 
15 platform; Fig. 2 is a block diagram of another embodiment of the invention wherein the 
buyer makes payment directly to the guaranteeing institution; 

Fig. 3 is a block diagram of the post-shopping experience for a user of the invention; 
Fig. 4 is a block diagram of the functions that an existing customer or new user proceeds 
through when visiting the web site platform of the invention; 
20 Fig. 5 is a block diagram showing the functions that a user proceeds through with customer 

service; 

Fig. 6 is a block diagram showing a user searching the database of the invention and 
consummating a transaction with a link to other web sites; 

Figs. 7a-7e demonstrate the algorithmic methods of communication for the various 
25 embodiments of the invention; 

Fig. 8 is a flow diagram showing the first international licensee embodiment of the 
invention in the first page; 

Fig. 9 is a flow diagram showing the first international licensee embodiment of the 
invention in the second stage; 
30 Fig. 10 is a fiow diagram of a second international licensee embodiment of the invention 

in the first stage wherein the financial institution of guarantee works directly with the international 
licensee; 

Fig. 1 1 is a fiow diagram of a second international licensee embodiment of the invention 
in the second stage; 

35 Fig. 12 is a third international licensee embodiment of the invention; 
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Fig, 13 is a fourth international licensee embodiment of the invention; 
Fig. 14 is a flow chart showing the connection being made between user and vendor; 
Fig, 15 is a flow chart showing the user application for credit; 
Fig. 1 6 is a flow chart showing the user log-in to the invention; 
5 Fig. 17 is a flow chart showing the user making a purchase through the methodology of the 

invention; 

Fig. 18 is a flow diagram of an alternative embodiment of the invention wherein both a 
guarantor bank and a vendor bank are used in the process; 

Fig. 19 is a flow diagram of another alternative embodiment of the invention wherein both 
10 a guarantor bank and vendor bank are used; 

Fig. 20 is a flow diagram of the preferred user login to a web site according to the 
invention; 

Fig. 21 is a flow diagram of the preferred purchase transaction according to the invention; 
Fig. 22 is a flow diagram of a flrst interaction with two guarantor banks; 
1 5 Fig. 23 is a flow diagram of a second interaction with two guarantor banks; 

Fig. 24 is a flow diagram of a preferred lockbox of the invention; 

Fig. 25 is an illustrative approval screen in a web page according to the invention prior to 
submission; 

Fig. 26 is an illustrative approval screen in a web page according to the invention after 
20 submission; 

Fig. 27 is an illustrative edit screen; 

Fig- 28 is a top-level flow diagram of the preferred web site of the invention in conjunction 
with customer web sites; 

Fig. 29 is an illustrative purchase screen; 
25 Fig. 30 is an illustrative invoice screen; 

Fig. 31 is an illustrative payment screen; 

Fig. 31 A is an illustrative flrst confirmation screen; 

Fig. 3 IB is an illustrative second conflrmation screen; 

Fig. 32 is a flowchart illustrating vendor recruitment; 
30 Fig. 33 is a flowchart illustrating buyer recruitment; 

Fig. 34 is a flowchart illustrating an exemplary trade show purchase; 

Fig. 35 is a flowchart illustrating shipment of a trade show purchase; 

Fig. 36 is an exemplary network that may be used in conjunction with electronic platform 
of the invention; 
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Fig. 37 is yet another exemplary network that may be used in conjunction with the 
electronic platform of the invention; 

Figs. 38, 39, and 40 are each a diagram illustrating the contents of selected fields of the 
database during an exemplary transaction; and 
S Fig. 4 1 is a screen display showing an exemplary report that is presented that shows the 

transaction history for a user of the electronic platform of Figs. 1 A, IB, IC and 2. 

Detailed Description of the Invention 
In one embodiment, the invention comprises a payment or credit arrangement process 
wherein payment of all transactions are guaranteed through a platform, and aligned guaranteeing 
10 financial institution (or guarantor bank). All users, whether buyers or sellers ("vendors") are put 
into a profile database that defines their credit amount, credit used, and credit available. A unique 
number is then assigned to each user that will be used as an identifying symbol to be held in the 
electronic database. This symbol, or digital representation thereof, represents a profile enabling 
users to obtain and utilize credit to facilitate purchases of goods, services, and other intangibles 
15 through the system. Tlie information and implementation of the invention is preferably distributed 
electronically over data lines into a worldwide web platform to facilitate users' purchase 
transactions or vendors' sales needs. 

The digitally produced symbol is delivered electronically via data lines to find targeted 
information, and enables the buyer to purchase goods, services, or other intangibles ordered 
20 through the system. A search engine is used to locate the required information over a network of 
profiled vendors. The same process operates in reverse to also link vendors to buyers. Information 
using software agents can be accessed electronically based on an Alchemy model that enables 
users to seek and match their specific requests. The unique symbol that is assigned for the 
vendor's profile, as well as a specific symbol representing the targeted audience of buyers, with 
25 additional symbols or digital representations for other information, allows for an efficient and 
easy-to-use exchange of information. Additionally, proprietary profiles can be maintained to 
facilitate electronic commerce for users within the database to exchange information and to target 
specific information to a targeted audience. 

Vendors benefit by reaching buyers through the system and offering credit to purchase 
30 their goods, services, or other intangibles. Competing advertising members can use the system to 
reach the attention of users who wish to seek information residing on the system as well. Vendors 
can use the credit system to sell to buyers within the profile database to ensure future payment of 
goods that are sold on a time-delay process unique to each of the profiled users. 

By electronically transmitting the symbol, the user can deliver a promise of compensation 
35 to be paid immediately, or in the future. By using software agents, the electronic database 
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transmits digital information electronically to those users who are seeking to receive compensation 
in exchange for releasing the items that the user/buyer has requested. The digitally produced 
symbol simultaneously instructs a third party to deliver a guarantee of compensation on behalf of 
each user. The third party guarantees compensation to the vendor in the form of either credit 
S insuring, full-factoring, or lending based upon accounts receivable. 

The platform streamlines the buying process and saves time by alleviating the need for 
C.O.D., prepayment with a Visa or MasterCard and excessive paperwork necessary for approval 
through multiple factoring banks. 

Often the vendor will need their money before they can ship the order: perhaps the money 
10 is needed to produce the order. In this case, called factoring, the vendor pays a higher fee to 
ProfitScape in order to obtain their money early. The vendor sells the receivable to the factor: 
once payment is made, the payment will be sent to the factor. This is done with or without the 
knowledge of the cardholder. 
Actors 

15 The following table documents some of the roles played by users of the system and a 

summary of how users interact with the system. A role or acior refers to one, possibly of many, 
motivations driving a user to interact with the system. The same user may have different roles at 
different times. 

20 



ACTOR 


INTENT 


Vendor 


The vendor, also known as the vendor, is selling 
product to the buyer and accepting payment via 
the system. The term Vendor is used as it is with 
consumer credit. 


Vendor/Spies 


1. Originate requests to guarantee payment, 
using trade show device or WUI, possibly even 
telephone. 

2. Check status of PENDING authorizations to 
determine whether to ship goods or not. 

3. View/print reports of outstanding System 
settlements. 


Vendor/Accounts Receivable 


1. View/print reports of outstanding/all/for a 
given cycle System settlements 

2. Track invoice number in system 

3. Receive statement of invoices being paid 
along with a check 


Vendor/Administrative User 


1 . View/ Edit Account 
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ACTOR 


INTENT 


Cardholder 


The cardholder, also known as the buyer, is 
buying goods and wishes to settle the purchase 
via the system. 


Cardholder/Buyer 


1. Use card to guarantee payment on orders, 
vendor can ship order without due diligence etc. 

2. View/print reports of transactions. 

3. Research invoice/PO discrepancies 


Cardholder/Accounts Payable 


1. View/print reports of outstanding/all/for a 
given cycle payables 

2. Remit payment for vendor invoice to card 
issuer. 


Cardholder/Administrative User 


1. View Accounts 


ProfltScape/New Cardholder Accounts 


1. Process pre-approve batches submitted by 
associations. 


ProfitScape/New Vendor Accounts 


1. Process vendor batches submitted by 
associations and web portals. 

2. Work with new vendors to ensure their full 
and proper use of service. 


ProfitScape/Customer Service 
Representative 


1. Respond to customer account inquiries 
(vendors and cardholders). 

2. Cancel authorizations. 

3. Manual card issue. 


ProfitScape/Risk & Quality Management 


1. View/print reports of late payers towards 
getting them to be on time 

2. Work with Guarantors* collection personnel. 


ProfitScape/GL Accounting 


1. View/print reports of transaction 
summary/detail to balance GL accounts 

2. Post journal entries to GL 


ProfitScape/System Accounts Payable 


1. Prepare and reconcile batch of vendor 
statements/checks. 

2. Print batch, z-fold into envelopes for mailing 

3. View/print reports of posted/unposted vendor 

checks 

4. Reconcile bank statement to unposted vendor 
checks. 


ProfitScape/System Accounts Receivable 


1. View/print reports of delinquent cardholders. 

2. Process received payments, one payment = 

multiple invoices. 
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ACTOR 


INTENT 


ProfltScape/ Administrative User 


1 . Configure system codes 




2. Create and maintain user profiles and security 




constraints. 


Guarantor/Administrative User 


1. View/Edit Accounts 


Guarantor/Collections 


1 . View/Edit Accounts 


Factor/Administrative User 


1. View/Edit Accounts 



Use Cases 

A use-case is a single scenario depicting how users are interacting with the system to 
achieve a specific goal. 
5 Process Pre-Approved Batch 

This case depicts the card issuer receiving a large number of proposed cardholders from a 
third party. The card issuer eliminates duplicates, creates the cardholder accounts, and submits 
their information to a guarantor for credit line approval. 

In one embodiment, an association submits a file to the card issuer, who in turn attempts to 
10 submit the file to the system. The system verifies file contents (headers, counts, formats, etc). The 
entire file is either accepted or rejected. If accepted, the file creates a batch in the database for 
processing. The card issuer processes batch, creating cardholder accounts where needed and 
marking each batch entry with the account number. Existing accounts are left alone, since the 
original association receives the fee (if any) for sourcing those records. The system marks any 
15 created cardholder records with the association as the source. In some cases the association will 
receive a permanent fee percentage of all transactions. The system generates batches for 
guarantors for credit line approvals. The card issuer submits credit line request batches to one 
or more guarantors. In response, guarantors submit a credit line response batch to the card issuer. 
The card issuer processes credit line batch, updating customer records. The card issuer prints a 
20 processing report (to printer or file) for the association to track results. 

Cards are then ready to be issued or other responses are generated. For example, customer 
service representatives for the card issuer can contact the applicant to counsel them towards getting 
approval, possibly from a different guarantor. 
Process Vendor Batch 

25 Associations can submit large groups of vendor records. Also, Vendors may sign 

themselves up for the service. Web portals may submit vendor batches as well. An exemplary 
process is set forth below that describes a process for creating new vendor accounts. 

An association or some other verified source submits a file to the card issuer. A CSR 
representative for the card issuer verifies file contents and either accepts or rejects the entire file. 
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If accepted, a New Vendor Accounts batch is created, waiting to be processed. Next, the card 
issuer processes file, creating vendor accounts where needed, and marking each batch record with 
the account number and status. In one embodiment, existing accounts are left alone. Letters are 
then issued to vendor informing them of their account, status, and usage procedures. 
5 Create Cardholder 

The card issuer can create a single cardholder account at a time as well as the batch pre- 
approved process. 
Issuing Cards 

One or more cards are issued to specific people within a company. The credit line 
10 authorization of a company can be divided among one or multiple card users. Even with multiple 
cards, the total authorization will not exceed the total credit line of a company. 

A company can: (i) authorize the entire credit amount to one person on one card; (ii) 
divide the entire credit amount among multiple people, each having their own card; (iii) allow a 
"key signatory" to access to the entire credit amount on a card, plus divide the entire credit amount 
15 among multiple people, each having their own card, or (iv) authorize the entire credit amount to 
multiple people, each having their own cards. As discussed, cards may be issued in large batches, 
sent out for embossing, or one at a time like temporary cards at a trade show. Again, batches are 
created, edited, posted. 

The following table summarizes each of the foregoing situations: 

20 



Card Type 


Description/Example 


Single Card 


The company is authorized a single card with 
the entire credit limit assigned to that one card. 


Multiple Cards 1 


A single credit limit is authorized to a 
company and the authorizing company "key 
signatory" later authorizes six users. Each user 
is then authorized, by the "key signatory", a 
specific amount of the credit limit, totaling up 
to; but, not more than the credit limit. The 
authorized amount may be equal or 
disproportional — depending on the "key 
signatories" perspective. (100% of the credit 
limit is divided between the key signatory and 
the six users). 
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Card Type 


Description/Example* 


Multiple Cards 2 


A single credit limit is authorized to a 
company and the authorizing company "key 
signatory" later authorizes six users. In this 
scenario, the "'key signatories" card is 
authorized for the total amount of the credit 
limit. Each of the other 6 authorized users are 
then authorized, by the "key signatory, a 
specific amount of the credit limit, totaling up 
to; but, not more than the credit limit. The 
authorized amount may be equal or 
disproportional — depending on the "key 
signatories" perspective. Typically, the 
aggregate amount of any two or more card's 
use may not exceed the total credit limit. 
(100% of the credit limit is divided among the 
six users; and, the key signatory has access to 
the entire credit limit). 


Multiple Cards 3 


A single credit limit is authorized to a 
company and the authorizing company "key 
signatory" later authorizes six users. In this 
scenario, any of the authorized card users, 
including the "key signatory", may spend the 
total amount of the credit limit; BUT, under no 
circumstances may the aggregate amount of 
any two or more card's exceed the total credit 
limit. (100% of the credit limit is equally 
available to all 7 users). 



In one embodiment of the invention, the card can be co-branded by a credit card provider. 
In this embodiment, at a point of purchase, the user can request to use the card as a credit card, or, 
5 alternatively, as a card as is described for use with the embodiiiients of the invention shown in 
Figures 1-41. Furthermore, in this embodiment, the card is associated with at least two credit 
limits: the first credit limit identifying a credit limit with respect to the credit card provider and a 
second credit limit associated with the use of the card in conjunction with the system shown in 
Figures 1-41. Furthermore, in one embodiment of the invention, the card contains two sets of 
10 account information: a first set is associated with the credit card provider and a second set is 
associated with respect to the use of the card in conjunction with the system shown in 
Figures 1-41. 
Tradeshow 

In one embodiment of the invention, custom cards are issued as part of a tradeshow. In 
15 this embodiment, the cards have identifying information displayed on the card thereby serving as a 
badge. The card may be activated by providing the credit vendor a credit application and 
requesting the credit vendor to activate the card. Once activated, the credit vendor provides an 
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insignia to the buyer. The buyer places the insignia on or near the card via an adhesive. The 
insignia identifies to sellers that the buyer has at least a threshold level of credit. In another 
embodiment of the invention, upon approving the buyer's application for a card, the buyer is 
provided a card having a certain color that is different than the individuals that have not been 
5 approved to receive credit. 
Create Vendor 

The card issuer can create a single vendor account at a time as well as part of the batch pre- 
approved process. 
Purchase Guarantee Pavment 
10 The following describes a process of guaranteeing payment for a transaction. First, a 

cardholder places order, e.g., verbal, PO, with a vendor. 

The vendor submits authorization request to ProfitScape/system (card #, expiration name, 
name, amount, PO). The system verifies credit balance, issues authorization code, decline, 
pending, or other response message. Exemplary response codes may be found in the Visa 2 
1 5 Specification. 

If amount requested puts cardholder over the cardholder's credit limit, a PENDING 
response is issued and submitted to the guarantor. The guarantor can approval the transaction 
and/or or increase the cardholder's credit limit. The card issuer can generate reports of PENDING 
authorizations to ensure that they are being answered in a timely manner. The vendor ships goods, 

20 sends invoice to the card issuer with an authorization code. The vendor sends an invoice to the 
cardholder requesting the cardholder to remit payment to the guarantor, or alternatively, the card 
issuer. In one embodiment, the card issuer has online forms for vendors to submit invoices. 

In one embodiment, the vendor incurs a payment term guarantee fee at the time of 
approval of the transaction. Each vendor obtains an approval for a specific buyer (i.e., one 

25 cardholder). Each approval can cover multiple invoices for a specific buyer (i.e., one cardholder). 
Each approval incurs a fee, relative to the total invoice amount. If an invoice is larger than the 
approved amount (e.g., due to taxes or shipping fees), a 2/2% fee (or more depending on length of 
terms) may be automatically charged against the extra amount. 
Receive Invoice 

30 After shipping the goods, the vendor sends the invoice to both the cardholder and to the 

card issuer. After the card issuer receives invoice(s), each invoice is marked with the 
authorization code. The invoice specifies the payment terms. Depending on the payment terms, a 
selected fee may be charged by the card issuer for the service of guaranteeing the total approved 
amount. In one embodiment, the fees are accessed on the basis of the total invoice amount, 

3S including tax and shipping charges. 
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In one embodiment, the fee schedule varies according to the length of time until the 
payment is due. The following table illustrates an exemplary fee schedule. 



Payment Terms 


hee 


Net JU 


2/2% 


Net an 


Z/2/0 


Net 90 


3% 


Net 120 


3'/j% 


Net ISO 


4% 


Net 180 


4'/2% 



If more than one invoice is received from a vendor, the vendor should include a summary 
5 sheet having totals for verification. 

The card issuer inputs an authorization code to fmd the transaction in the database, and 
then inputs the invoice number and total. The card issuer logs the invoice and sends the invoice to 
the guarantor of the transaction both physically and as an electronic item. 
Guarantor Receives Pavments 

10 Payments are received by the guarantor, which sends an electronic log of settlements to the 

card issuer. It is noted that in one embodiment, the buyer sends the payments directly to the card 
issuer. The system creates the appropriate payment transactions and computes the guarantor's 
fee, creating a transaction object in the platform for that as well. The card issuer applies 
payments to the invoice. The guarantor takes a fee, based on the total amount of the invoice, and 

15 then send the payments on to the card issuer. One payment may be applied to multiple invoices. 
A partial payment may be applied to an invoice. 

The card issuer distributes to the vendor the payment, less fees any transaction fees. The 
vendor receives the payment, less fees, based on the total amount of the INVOICE (not the 
amount received). The vendor may bill the buyer for the difference between the total invoice and 
20 the amount remitted. In the event the payment is less than the total invoice amount due to 
payment terms (e.g., 2%/IO Net 30), the vendor is responsible for issuing a credit for the buyer 
Card Issuer Issues Vendor Checks 

A payables batch is created in the system. After editing, the batch is sent to a A/P system 
to actually print checks. Optionally, the card issuer can print the checks. 

25 
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Cycle End Processing 

The vendors each receive a cycle-end statement summarizing all transactions and 
providing updated information. This marks a regular contact point, where marketing materials 
may be included with the mailing. Some may elect to receive such transmissions electronically, 
5 e.g., CD-ROM, diskette, ftp, email. 
Issue Cards fBatch, Single, Re-issue) 

Cards may be issued in large batches, sent out for embossing, or one at a time. 
Buyer Credit Advance 

The buyer is responsible for paying for the goods and services that have been purchased 
10 from the seller within a predetermined time period, e^^., 30, 60, 90 days. In one embodiment, the 
start of the due date time period is triggered after the seller transmits the goods to the buyer or, 
alternatively, after the seller performs services for the buyer. 

In one embodiment of the invention, the buyer may defer payment by paying a selected 
fee. In return, the recipient of the selected fee pays all or some of the ftinds that are owed by the 
15 buyer. 

For example, with respect to the system shown in Fig. 1 B, the buyer may request the credit 
vendor to defer payment to the re-factor company. In exchange for receiving the selected fee, the 
credit vendor pays the seller after the predetermined time period. Also, the credit vendor transmits 
a selected fee to the re-factor company for the re-factor company's involvement with the initial 
20 transaction between the buyer and the seller. Alternatively, instead of the credit vendor, the re- 
factor company can accept delayed payment and in return for the delayed payment, charge the fee 
and pay the credit vendor prior to the expiration of the predetermined time periods, eg,, 30, 60, 90 
days. The credit vendor then pays the seller the monies owed the seller by the buyer minus any 
transaction fees. 

25 Furthermore, for example, with respect to the system shown in Fig. IC, the buyer may 

request the credit vendor to receive delayed payment for a fee. In return for the fee, the credit 
vendor pays the seller prior to the expiration of the predetermined time period. 
View Accounts 

In one embodiment, buyers and sellers may retrieve their account information from the 
30 credit server. Account information can include: credit limits, past transactions, billing information, 
etc. In this embodiment, the credit vendor maintains a server computer that is operably connected 
to a network. The network may include any type of electronically connected group of computers 
including, for instance, the following networks: Internet, Intranet, Local Area Networks (LAN) or 
Wide Area Networks (WAN). In addition, the connectivity to the network may be, for example, 
35 renfiote modem, Ethernet (IEEE 802.3), Token Ring (IEEE 802.5), Fiber Distributed Datalink 
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Interface (FDDI) or Asynchronous Transfer Mode (ATM). Note that computing devices may be 
desktop, server, portable, hand-held, set-top, or any other desired type of configuration. As used 
herein, an Internet includes network variations such as public internet, a private internet, a secure 
internet, a private network, a public network, a value-added network, an intranet, and the like. 
S Using a client computer that is connected to the network, the client computer can retrieve 

account information. An exemplary report showing account information is shown in Figure 41. In 
one embodiment, the server computer allows the user to contest certain transactions that are 
identified in the account information. Upon contesting a transaction, the contesting party is 
afforded an opportunity to associate one or more messages with the contest. In this regard, each 

10 transaction has an electronic storage bin to hold communications between the buyer and the seller 
for the selected transaction. 

In one embodiment, if the transaction is contested by the buyer, the message is 
automatically transmitted via electronic mail to an agent for the seller and stored in the electronic 
storage bin. Furthermore, in one embodiment, if the transaction is contested by the seller, the 

1 5 message is automatically transmitted via electronic mail to an agent for the buyer and stored in the 
electronic storage bin. Once received by the non-contesting party, the contesting party is 
presented with an opportunity to reply via electronic mail. Using the storage bin, the 
communication history between the buyer and seller may be reviewed. Furthermore, in one 
embodiment of the invention, the non-contesting party can change the terms of the transaction to 

20 end the dispute. - 

In one embodiment of the invention, a buyer is afforded an opportunity to delay payment 
with respect to one or more of the transactions. In this embodiment, when the user views their past 
transactions, the buyer is presented a selectable icon proximate to each of the transactions for 
which that buyer owes payment. By selecting the selectable icon, the user indicates a request to 

25 extend the due date for paying the due fees. In response to the selection, the server computer 
adjusts the due date for the transactions and assigns a due date extension fee to the buyer's account. 
Furthermore, at a predetermined point, the server computer pays the seller the monies that are 
owed to seller by the buyer. 

In another embodiment of the invention, a seller is afforded an opportunity to receive 

30 payment prior to agreed upon terms with the credit vendor. In this embodiment, when the seller 
views past transactions, the seller is presented with a selectable icon proximate to each of the 
transactions in which the seller is to receive payment. By selecting the selected icon, the seller 
indicates a request to receive payment for the funds immediately. In response to the selection, the 
server computer pays the seller the monies owed minus an advance fee. 
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It is noted that since a buyer may also be a seller to other buyers, the buyer and seller 
reporting screens may be integrated into a single screen display. 

System Description 

Attention is now directed to the figures. Fig. 1 A is a flow diagram of a first embodiment 
S of the invention showing the purchase and fulfillment between a buyer, vendor and guaranteeing 
financial institution using the method of the invention. Referring to Fig. 1, the buyer makes a 
purchase from the vendor with a guaranteed credit line as established in the profile database 10. 
The purchase order is then being forwarded to the vendor for fulfillment 12. Then the receivable is 
reassigned to the guaranteeing financial institution for a guarantee of the receivables 14, the 

10 purchase order is returned to the buyer for the buyer's records 16. The vendor ships the order with 
a copy of the invoice and terms back to the buyer 18, for example, net 30, net 60, or net 90. Then 
the vendor sends shipment confirmation and a copy of the invoice to the platform for the 
invention, which in one embodiment,, is entitled "ProfitScape" (hereinafter referred to as the 
platform), on an e-commerce web site 20. Next the buyer makes payment to the platform based 

1 5 upon the vendor terms 22, and the platform forwards payment to the vendor 24, minus a negotiated 
percentage. The platform profile database maintains credit records and transfers all monies from 
the buyer to the vendor minus a negotiated percentage or transaction fee, for example 8-12% of the 
transaction. The guaranteeing financial institution will review the accounts periodically, for 
example every 90 days, for buyer credit line limits. Also periodically, for example every 30 days, 

20 the platform reconciles with the guaranteeing financial institution for a percentage of all gross 
revenue of the platform's guaranteed electronic commerce transactions. 

Fig. IB is another embodiment of the invention. Fig. IB is a flow diagram of a second 
embodiment of the invention showing the purchase and fulfillment between a buyer, seller and a 
credit vendor. It is noted that although only one buyer is shown, the electronic platform can be 

25 used in connection with large numbers of buyers. 

Referring to Fig. IB, at a step 51, a buyer provides credit information via an application to 
a credit vendor. Next, at a step 52, the credit vendor forwards the information to a re-factor 
company. The re-factor company evaluates the credit information and determines a credit limit for 
the buyer. At a step 53 the re-factor company transmits the credit limit for the buyer to the credit 

30 vendor. Continuing to a step 54, the credit vendor transmits one or more cards to the buyer. In one 
embodiment, the card has an electronic strip having a magnetically imprinted card number. 
Furthermore, the card may have an associated personal identification number. 

Moving to a step 55, the buyer contacts a seller and offers to purchase goods or services 
that are provided by the seller. At the step 55, the buyer provides the seller their card or 

35 alternatively the buyer's account information. 
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Next, at a step S6, the seller provides the credit vendor, via a transaction device, the 
transaction information. The transaction device can include: a computer, a hand held device, a 
cash register, or other electronic device. In one embodiment of the invention, the transaction 
information comprises a merchant identifier, the buyer account number (the card number), the 
5 name on the card, an expiration date that is associated with the card, and an estimated transaction 
amount. 

The credit vendor determines whether the transaction amount would cause the buyer to 
spend in excess of the buyer's credit limit. Assuming the buyer has sufHcient credit, the process 
moves to a step 57 wherein the credit vendor transmits approval to the seller computer for the 
10 transaction. Furthermore, the credit vendor records the transaction information to facilitate 
evaluating further purchases of the buyer. 

Continuing to a step 58, the seller ships the goods or performs the services specified by the 
contract. In return, the seller receives from the credit vendor the right to receive payment no later 
than a predetermined period. In one embodiment of the invention, the predetermined period is no 
1 5 later than 1 80 days or whenever the re-factor company receives payment, whichever is sooner. 

Next, at a step 61, the buyer makes payment to the re-factor company. Continuing to a 
step 62, the re-factor company pays the credit vendor minus a first transaction fee. Proceeding to a 
state 63, the re-factor company pays the seller minus a second transaction fee. It is noted that in 
one embodiment of the invention, for a predetermined fee, the seller can borrow against the 
20 guaranteed received payment. 

Fig. IC is a flow diagram of a third embodiment of the invention showing the purchase and 
fulfillment between a buyer, vendor and guaranteeing financial institution. It is noted that although 
only one buyer is shown, the invention can be used in connection with large numbers of buyers. 

Referring to Fig. IC, at a step 71, a buyer provides credit information via an application to 
25 a credit vendor. Next, at a step 72, the credit vendor forwards the information to a credit insurer. 
Tlie credit insurer evaluates the credit information and determines whether it will insure the 
transaction. At a step 73, the credit insurer transmits the credit limit for the buyer to the credit 
vendor. The credit vendor may transmit one or more cards to the buyer. 

Moving to a step 74, the buyer contacts a seller and offers to purchase goods or services 
30 that are provided by the seller. Upon agreeing to the terms of a deal, the buyer provides the seller 
their card or alternatively provides the buyers account information. 

Next, at a step 75, the seller provides the credit vendor, via a transaction device, the 
transaction information. In one embodiment of the invention, the transaction information 
comprises a merchant identifier, the buyer account number (the card number), the name on the 
35 card, an expiration date that is associated with the card, and an estimated transaction amount. 
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The credit vendor determines whether the transaction amount would cause the buyer to 
spend in excess of the buyer's credit limit. Assuming the buyer has sufficient credit, the process 
moves to a step 76 wherein the credit vendor transmits approval to the seller's transaction device. 
Furthermore, the credit vendor records the transaction information to facilitate evaluating further 
5 purchases of the buyer. 

Continuing to a step 77, the seller ships the goods or performs the services specified by the 
contract. In return, the seller receives from the credit vendor the right to receive payment no later 
than a predetermined period. In one embodiment of the invention, the predetermined period is no 
later than 1 80 days or whenever the credit vendor receives payment, whichever is sooner. 

10 Next, at a step 78, the buyer makes payment to the credit vendor. It is noted that in one 

embodiment of the invention, for a predetermined fee, the seller can borrow against the guaranteed 
received payment. Moving to a step 79, the credit vendor pays the seller. Fig. 2 is another 

embodiment of the invention. In Fig. 2, the buyer makes a purchase through the guaranteeing 
financial institution with a guaranteed credit line 26. In one embodiment, the vendor then obtains 

15 from the guaranteeing financial institution an authorization code for the amount of the intended 
purchase, including tax and shipping if known. Once authorization is obtained (usually within 
seconds), the vendor may ship the order knowing that payment is guaranteed. The purchase order is 
then forwarded to the vendor for fulfillment 28 and the purchase order is then returned to the buyer 
for the buyer's records 30. Then the vendor ships the order with a copy of the invoice and terms to 

20 the buyer 32, and the vendor sends shipment confirmation and a copy of the invoice to the 
guaranteeing financial institution 34. In one embodiment, the vendor notes on the buyer's copy of 
the invoice to remit payment to the guaranteeing financial institution 34. The buyer the makes 
payment to the guaranteeing institution based upon the vendor's terms 36, and the institution 
forwards payment to the vendor minus the institution's negotiated percentage 38. 

25 Fig. 3 is a block diagram demonstrating the post-shopping experience of the buyer using 

the methodology of the invention. The user first shops and then views their order, and before 
checking out, chooses a form of payment, be it either a credit card, or through the platform of the 
invention. If a credit card is chosen as the method of payment, the transaction proceeds through 
the platform of the invention. If the user is enrolled in the platform of the invention, their 

30 transaction is guaranteed. The user is also offered the choice of joining and becoming a member of 
the platform. 

Fig. 4 shows the process that a user proceeds through when first logging on to the platform 
of the invention. First the existing customer or the new user visits the web site having the 
platform of the invention 40. The new user applies for membership and a line of credit with 
35 guaranteed receivables 42. An existing user is shown logging in with their user name and 
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password 44, and the existing customer or new user is forwarded to the appropriate web sites for 
purchases 46. Applications for credit and guarantees are forwarded to the financial institution for 
review 48. If the application for credit has been denied, the customer is then notified SO. If the 
application for credit has been approved, the customer is assigned a guaranteed credit limit 52, as 
S well as an "ID" and is then entered into the user profile database. 

Fig. S is a block diagram demonstrating an approved customer 54 being forwarded to 
customer service so that customer service can gather information 56 and create a user database 
profile on their company, products, target market, history, terms, etc. Example data collected for 
the user's profile includes: name, address, contact information, primary industry, credit insured 

10 amount, payment history, credit usage, target marketplace, products offered, services offered, 
inventory, buying trend data, and Internet usage data. 

Fig. 6 is a block diagram demonstrating a user searching the profile database. A user 
queries the database through a search engine for specific information 58. Data is searched from the 
database and returned to the user 60. Then the user accesses a web site from a returned data link 

15 62, and the user consummates an electronic commerce transaction 64 such as that shown in Fig. 1 . 

Fig. 7 shows the algorithm methods for the various embodiments of the invention. In Fig. 
7a the buyer, seller, and guaranteeing institution cannot communicate with each other but only with 
the platform for the invention. In Fig. 7b the buyer and seller only communicate with the 
guaranteeing institution and not with each other. In Fig. 7d the buyer and guaranteeing institution 

20 can each only communicate with the seller, but the seller can communicate with either or both of 
the buyer and guaranteeing institution. In Fig. 7e the seller and the guaranteeing institution can 
each only communicate with the buyer, but the buyer can communicate with either or both of them. 

Fig. 8 shows a flow diagram of an embodiment of the invention wherein the method of the 
invention includes an international licensee. First a user applies for a credit line through the 

25 international licensee 66. Then an application is entered into the database of the invention 68, and 
that application is forwarded to the guaranteeing financial institution 70. Then the applicant who is 
approved is assigned a line of credit and a user ID, and the database is then updated with their 
information 72. The user and licensee are then notified 74. At this point, the process proceeds as 
shown in Fig. 9. If the application is denied, the applicant and licensee are notified accordingly 76. 

30 Fig. 9 demonstrates the process that proceeds after the applicant has been approved in Fig. 

8. The international buyer accesses the marketplace through a licensee 78. Then the platform's 
buyer makes an international purchase on the platform with the user's ID 80, Next the user ID and 
credit availability are checked through the database and the guaranteeing financial institution 82 
and 82'. Then the seller receives the order with the guaranteed receivables 84, and the transaction 

35 has been completed and the order is shipped to the buyer 86. 



-24- 



wo 01/58242 PCTAJSOl/04515 

Fig. 10 is a flow diagram for a second embodiment of the international licensee application 
of the invention. First the user applies for a credit line through an international licensee 88. Then 
the application is forwarded to the guaranteeing financial institution 90. If the application is 
approved, the applicant is then assigned a line of credit and a user ID 92. The user and licensee are 
5 then notified. At this point, the process proceeds as shown in Fig. 1 1. If the application is denied, 
the applicant and licensee are accordingly notified 94. 

Fig. 1 1 represents the next stage in the process after having completed those steps in Fig. 
10. In Fig. 11, the international buyer accesses the marketplace through a licensee 96 and the 
platform buyer makes an international purchase 98 on the platform of the invention with the user 
10 ID. Then the user ID and credit availability are checked through the guaranteeing financial 
institution 100. The seller receives the order with the guaranteed receivables 102, the transaction is 
completed and the order is shipped to the buyer 104. 

Fig. 12 is a third embodiment of the international licensee application of the invention. In 
Fig. 12, the guaranteed buyer makes a purchase from a vendor on an international licensee 
15 platform 106. Then the user ID and password are passed to a module 108 which allows the 
communication with the database of the invention, and the ID and credit availability are checked 
through the database, as well as the guaranteeing financial institution 110 and 1 10'. The vendor 
web site receives verification 112, and the transaction is completed and the order is then shipped to 
the buyer 1 14. 

20 Fig. 13 is a fourth embodiment of the international licensee application of the invention 

wherein the communication occurs directly with the guaranteeing financial institution. First, the 
guaranteed buyer makes purchases from a vendor on the international licensee platform 1 16. Then 
the user ID and password are passed to a module which allows communication with the database of 
the invention 1 18. Next the user ID and credit availability are checked through the guaranteeing 

25 financial institution 120. The vendor web site receives verification 122, and the transaction is 
completed and the order is then shipped to the buyer 124. 

Fig. 14 is a flow chart demonstrating vendors' direct marketing to existing registered users 
(buyers) of the invention. The buyer logs on and sees offers being retrieved from the database, 
and chooses whether or not to accept the offer. If the offer is accepted, the transaction is 

30 concluded. If the offer is not accepted, the user continues on through the web site. The vendor 
creates offers and then sends them to the database for storage. The vendor then creates a user 
profile from the information off of the database. The database then compares the profile created by 
the vendor with existing customer profiles. The invention then creates a list of matching users 
who wish to see offers of this type and proceeds to offer them to those users the next time that they 

35 log on. 
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Fig. 15 is a flow chart showing the user applying for credit with the methodology of the 
invention. The user first applies for a credit line» and that information is then added to the 
database. The information is then submitted to a financial institution and the financial institution 
either approves or disapproves the credit application. If the application is not approved, the user is 
S informed of the result. If the application is approved, the amount of credit is recorded for the user 
and the user is accordingly informed of approval and the amount of credit. For example, an 
applicant applies for a "net 30 card." This card is similar in appearance to a credit card. Should 
the applicant be approved for the net 30 card, then they will be able to purchase goods and services 
immediately, and upon receipt the guaranteeing institution or platform of the invention will 

10 guarantee payment within thirty days to the vendor. The applicant can apply for the card either 
manually or electronically. Information received from the candidate is then entered into a database 
which is forwarded to a guaranteeing fmancial institution. The guaranteeing financial institution 
then reviews the application information and issues an insured line of credit if the applicant is 
approved. Once the applicant is approved, the guaranteeing financial institution notifies the 

15 platform of the insured credit line and guarantees payment of receivables. Then the net 30 card is 
issued to the applicant, who is now a registered user of the platform of the invention. The user's 
transactions are then checked through the platform profile database for available credit and 
amounts adjusted. At the end of each day, the platform of the invention keeps the guaranteeing 
financial institution updated on all user accounts' status. This methodology insures the vendor's 

20 receivables. 

Fig. 16 is a flow chart demonstrating the steps that a user proceeds through in logging on 
to the web site containing the platform of the invention. The user first arrives at the public Web 
site and enters their login ID. The site then compares their ID and password to those recorded in 
the database. If the log-in is not valid, then the user is refused access and is returned to the public 

25 Web site. If the log-in is valid, then the user preferences are retrieved from the database and are 
customized to provide a personalized page displayed to the user. The user then continues with 
member-only options within the system. 

Fig. 17 is a flow chart demonstrating a user making a purchase using the methodology of 
the invention. The user first attempts to conclude the transaction and the platform of the 

30 invention ascertains the user's identity and compares their transaction with an available credit 
balance stored in the database. If their available balance is not adequate, then the transaction is 
denied. If the available balance is adequate, then the transaction proceeds and the invention 
subtracts the transaction total from the available balance, and the order is confirmed to the user, the 
vendor is notified of the purchase order, and the user receives a copy of the purchase order. Next, 

35 the receivables are reassigned to the financial institution and the vendor receives notification of the 
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purchase order and fulfills the purchase order. Once the receivables are reassigned to the financial 
institution, then the financial institution receives notification of that reassignment. Once the 
vendor notifies the platform of the fulfillment of the order and has sent the user the merchandise, 
the user is then billed. If the user does not pay the bill, then the financial institution is notified who 
5 then pays the platform who in turn pays the vendor. If the user does pay the bill, then their 
payment is added to the available credit in their account. 

Fig. 18 is a flow diagram of a third embodiment of the invention. First the buyer selects 
the platform guaranteed receivables method as the method of payment 126. The e-commerce 
backend forwards purchase information to the platform profile database 128. Available credit is 

10 checked from the user's profile and new applicants are processed 130. Then the profile database is 
updated accordingly 132. The buyer is notified and if approved, the vendor, or seller, is also 
notified to ship 134 and 134'. Then the buyer makes payment to the guarantor bank according to 
the terms set forth by the vendor, or seller 138. The profile database is then updated accordingly 
140. The guarantor bank processes the payment and forwards payment to the platform and vendor 

1 5 bank 142. Then the vendor bank credits the vendor, or seller 1 44. 

Fig. 19 is a flow diagram of a fourth embodiment of the invention. In this embodiment, 
the buyer selects the platform guaranteed receivables method as the method of payment 146. The 
e*commerce backend forwards purchase information to a processor 148. The processor forwards 
information to the guaranteed receivables issuer which is the platform of the invention 150. Then 

20 the available credit is checked, new applicants are processed, and the profile database is updated 
accordingly 152. The buyer is notified of either approval or rejection of their application 154. If 
approved, the vendor, or seller, is notified to ship. The buyer makes payments to the guarantor 
bank lock box according to the terms set forth by the vendor, or seller 156. Next, the database and 
credit limit are updated accordingly 158. Then the guarantor bank processes payment and 

25 forwards payment to the platform and vendor bank 160. Then the vendor bank credits the vendor 
162. 

Figs. 20-40 further illustrate the invention as noted in the brief figure descriptions, above. 
The embodiments presented in the figures are not meant to limit the applications of the invention. 
The methodology of the invention has application in buying and selling, as well as lending based 
30 upon accounts receivables, in addition to credit insuring purchases. 

Abstract Model 

The platform comprises one or more computer implemented modules. As can be appreciated 
by one of ordinary skill in the art, each of the modules comprise various sub-routines, procedures, 
definitional statements, and macros. Each of the modules are typically separately compiled and 
35 linked into a single executable program. The modules may be arbitrarily redistributed to one of the 
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other modules, combined together in a single module, or made available in a shareable dynamic link 
library. Optionally, as can be appreciated by one skilled in the art, one or more of the modules may 
be designed using hardware. 

The modules may be written in any programming language such as C, C++, BASIC, 
5 Pascal, Java, and FORTRAN and ran under the well-known operating system. C, C++, BASIC, 
Pascal, Java, and FORTRAN are industry standard programming languages for which many 
commercial compilers can be used to create executable code. 

The following sections describe exemplary software-implemented classes that may be 
defmed by selected ones of the modules. 
10 Company 

The company class provides a common base class for the four types of companies involved 
in the system: Merchants, Cardholders, Factors, and Guarantors. 



id: int 


System generated identification number. 


industryCode: Code 


Type of industry the company belongs to. 


names: List of CompanyName 


Companies have a primary name and zero or 

more DBA's. 


addresses: Map of List of Address 


Companies have one or more addresses. Each 
address is marked as to its usage. 


contacts: Map of List of Contact 


Companies have one or more contacts. Each 
contact is marked as to its usage. 


taxID: Biglnteger 


Federal tax id or VAT code. 






int getlDQ 


Get the company identification number. 


Code getlndustryCode () 


Get the industry code. 


void setlndustryCode (Code newlndustry) 


Set the industry code. 


Iterator getNames () 


Get an iterator over the list of names, in 
sequence. The first is the primary, any 
subsequent are DBA's. 


Iterator getDBANames () 


Get an iterator over just the DBA's. 


Iterator getAddresses () 


Get an iterator over all addresses, sorted by type 
by sequence. 


Iterator getAddresses (Code addressType) 


Get an iterator over alt addresses of the 
specified type sorted by sequence. 


Iterator getContacts () 


Get an iterator over all the contacts, order by 
type by sequence. 


Iterator getContacts (Code contactType) 


Get an iterator over all contacts of the given 
type, order by sequence. 


Biglnteger getTaxID () 


Get the tax id or VAT number. 



15 Code 

The Code class represents all fields that store a coded value, referenced within the Codes 

table. 
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codeType: String 




codeName: String 




codeCharacterValue: String 




codelntegerValue: long 




description: String 





CompanvName 

CompanyName represents a single company name, which may be one of many names a 
company goes by. 



CompanyName 



I name: String ] The company name. 

5 

Address 

Address provides a postal address. 



Address 


type: Code 


The address type. 


linel: String 


Number and street, etc. 


line2: String 


Overflow. 


line3: String 


Overflow, 


city: String 




stateCode: Code 




postaiCode: Biglnteger 




countryCode: Code 




attention: String 





10 Contact 

The Contact class represents a person and their contact information as well as a company's 
primary contact information. 



Contact 


type: Code 




lastName: String 




firstName: String 




middleName: String 




jobTitle: String 




department: String 




uri: String 




email: String 




phone: String 




fax: String 




mobile: String 




pager: String 




notes: String 




address 1: String 
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address2: Siring 




address3: String 




city: String 




stateCode: Code 




postalCode: Biglnteger 




countryCode : Code 





Merchant 

The Merchant class provides information regarding a single merchant within the system. 



MerchantHome 

The MerchantHome class provides methods for creating, finding, and deleting Merchants. 



MerchantHome 


create (...) 


Create a new Merchant. 


find ByPrimary Key (MerchantPK pk) 


Find by primary key. 


Name[] getNextNames (Name first, int 

count) 


Get a list of names greater than or equal to the 

given one. 


Name[] getPreviousNames (Name last, int 
count) 


Get a list of names less than or equal to the 
given one. 



Cardholder 



The cardholder class represents a single cardholder within the system. 



Cardholder extends Company 


guarantorlD: GuarantorPK 


The guarantor issuing this line of credit. 


limit: BigDecimal 




limitDate: Date 




limitSource: String 




customerlD: String 




association: AssociationPK 




source: String 




creditStatus: Code 





CardholderHome 

The CardholderHome class provides methods for creating, finding, and deleting 
Cardholders. 



CardholderHome 


create (...) 


Create a new Cardholder. 


findByPrimarylCey (CardholderPK pk) 


Find by primary key. 


Name[] getNextNames (Name first, int 

count) 


Get a list of names greater than or equal to the 

given one. 


Name[] getPreviousNames (Name last, int 
count) 


Get a list of names less than or equal to the 
given one. 
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Card 


limit: BigDecimal 




limitDate: Date 




limitSource: String 




PIN: String 




name: String 




companyName: CompanyName 


Which company name is on the card, it preferably is 
one of the defined ones. 


allianceName: CompanyName 


An alliance name if any. 


issucDate: Date 




expireDate: Date 




badgeNumber: String 





Guarantor 



Guaranior extends Company 


minimum: BigDecimal 




feePercentage: BigDecimal 





GuarantorHome 

The GuarantorHome class provides methods for creating, finding, and deleting Guarantors. 



GuarantorHome 



same as MerchantHome 



15 



10 Factor 

The factor class represents a single factor. 



Factor Home 

The FactorHome class provides methods for creating, finding, and deleting Factors. 
Association 

The Association Class represents a company with a business relationship. 



20 AssociationHomc 

The AssociatonHome class provides methods for creating, finding, and deleting associations. 



25 



Transaction 

The transaction class represents a transaction. 



Transaction 


id: String 




timestamp: Timestamp 




companylD: CompanyPK 




company2ID: CompanyPK 




type: Code 
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amount: BigDecimal 




batchID: String 





Transaction Home 

The TransactionHome class provides methods for creating, finding, and deleting 
Transactions. 

Various other classes may be used to represent other portions of the system such as 
merchant invoices, cardholder payment, and a merchant statement/check. 

Although the invention has been described in detail with particular reference to these 
preferred embodiments, other embodiments can achieve the same resuhs. Variations and 
modifications of the invention will be obvious to those skilled in the art and it is intended to cover 
in the appended claims all such modifications and equivalents. The entire disclosures of all 
references, applications, patents and publications cited above are hereby incorporated by reference. 
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Appendix A 
Database Schema 

It is noted that a number of different database schemas may be used with respect to the 
platform profile database. Set forth below are exemplary tables that may be used in conjunction 
with one embodiment of the platform profile database. 

Table 1 : System Users 

CREATE TABLE SYSTUSR 
( 



ID 


INTEGER NOT NULL, 


{ unique id 


) 


LGNID 


CHARdS) NOT NULL. 


{ Igin id 


) 


CDUSRID 


INTEGER NOT NULL. 


{ user class 


} 


PWD 


CHAR (IS) NOT NULL, 


{ password 


) 


PWDDT 


DATE NOT NULL. 


{ password date 


) 


NAM 


CHAR (SO) NOT NULL. 


{ full name 


} 


ACT 


CHAR(l) NOT NULL. 


{ active Y/N 


) 


LGNCNT 


INT NOT NULL, 


{ login count 


} 


LGNBAD 


INT NOT NULL. 


{ login bad count 


} 


LGNDTTM 


DATBTIME YEAR TO SECOND. 


{ last login date 


} 


ATDTTM 


DATETIME YEAR TO SECOND. 


{ last login attmp } 


ACTDT 


DATE. 


{ active date 


) 


EXPDT 


DATE, 


{ expire date 


} 


DTA 


CHAR(SO} , 


{ any data to associate to user } 


CRTUSRID CHAR (15) NOT NULL. 


{ create user id 


} 


CRTDTTM 


DATETIME 


{ create datetime 


) 




YEAR TO SECOND NOT NULL, 






CRTSRVR 


CHAR{15) NOT NULL, 


{ create server 


> 


CRTCLNT 


CHAR (15) NOT NULL, 


{ create client 


) 


CHGUSRID CHAR (15) NOT NULL, 


{ change by user 


) 


CHGDTTM 


DATETIME 


{ change datetime 


> 




•YEAR TO SECOND NOT NULL, 






CHGSRVR 


CHARdS) NOT NULL. 


{ change server 


) 


CHGCLNT 


CHAR (15) NOT NULL, 


{ change client 


} 
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PRIMARY KEY (ID) CONSTRAINT SYSCUSRPK, 
CHECK (ACT IN ('Y\ 'N')) CONSTRAINT SYSCOSRl, 
UNIQUE (LGNID) CONSTRAINT SYSCUSR2 
) LOCK MODE ROW; 



Table 2: User Groups 
(Map a user to a set of zero or more groups) 



CREATE TABLE SYSTUSRG 
( 

ID INTEGER NOT NULL. 

USRID INTEGER NOT NULL, 
GRPUSRID INTEGER NOT NULL, 



{ unique id ) 
{ user id } 
{ group user id } 



) ; 



PRIMARY KEY (ID) CONSTRAINT SYSCUSRGPK, 
UNIQUE (USRID. GRPUSRID) CONSTRAINT SYSCUSRGl, 

FOREIGN KEY (USRID) REFERENCES SYSTUSR(ID) CONSTRAINT SYSCUSRGFKl, 
FOREIGN KEY (GRPUSRID) REFERENCES SYSTUSR(ID) CONSTRAINT SYSCUSRGFK2 



CREATE TABLE SYSTMNU 



Table 3: System Menu 



ID INTEGER NOT NULL, 

TYP CHAR(l) NOT NULL, 

FNAM CHAR (100) , 

PNAM CHAR (100). 

DESC CHAR (100) NOT NULL, 

MNUID INTEGER, 



{ unique id ) 

{ M B Menu, F = Function, L = Link ) 
{ public alias for program } 

{ program name } 
{ human description of function } 
{ parent menu } 



PRIMARY KEY (ID) CONSTRAINT SYSCMNUPK. 

FOREIGN KEY (MNUID) REFERENCES SYSTMNU (ID) CONSTRAINT SYSCMNUFKl, 
CHECK (TYP IN CM', 'F', 'L')) CONSTRAINT SYSCMNUl 



) LOCK MODE ROW; 
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CREATE TABLE SYSTUSRP 



Table 4: User Permissions 



ID INTEGER NOT NULL, 

MNUID INTEGER NOT NULL, 

USRID INTEGER NOT NULL, 

PRM CHAR(l) NOT NULL, 



{ unique id } 

{ menu id } 

{ user id ) 

( N a No Access, R s Read, P » Full } 



PRIMARY KEY (ID) CONSTRAINT SYSCUSRPPK, 
UNIQUE (MNUID, USRID) CONSTRAINT SYSCUSRPl, 

FOREIGN KEY (MNUID) REFERENCES SYSTMNUdD) CONSTRAINT SYSCUSRPFKl 



) LOCK MODE ROW; 

Table 5: Unique IDs 

CREATE TABLE SYSTID 
( 

NM CHAR (20) NOT NULL, 

LSTID INT8 NOT NULL, 



PRIMARY KEY(NM) 
) LOCK MODE ROW; 

Table 6: Authorization Responses 

CREATE TABLE N30TCDRSP 
( 

ID INTEGER NOT NULL, 

DESC CHAR (20) NOT NULL, 



PRIMARY KEY (ID) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

Table 7: Application Status 

CREATE TABLE N30TCDAST 
( 

ID INTEGER NOT NULL, 
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DESC CHAR (20) NOT NULL. 

PRIMARY KEY (ID) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

Table 8: Payment Terms 

CREATE TABLE II30TCDPMT 
( 

ID INTEGER NOT NULL, 

DESC CHAR (20) NOT NULL, 
FEE DECIMAL (8, 4) NOT NULL, 

PRIMARY KEY (ID) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

Table 9: Transaction Types 

CREATE TABLE N30TCDTRN 
( 

ID INTEGER NOT NULL, 

DESC CHAR (20) NOT NULL, 

PRIMARY KEY (ID) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

Table 10: Transaction Detail Types 

CREATE TABLE N30TCDTRND 
( 

ID INTEGER NOT NULL, 

DESC CHAR (50) NOT NULL, 
BADJ MONEY(14,2) NOT NULL , 
CADJ MONEY (14, 2) NOT NULL , 

PRIMARY KEY (ID) . 
UNIQUE (DESC) 
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) LOCK MODE ROW; 

CREATE TABLE N30TCDIND 

( 

ID INTEGER NOT HULL, 

DESC CHAR (50) NOT NULL, 

PRIHARY KEY (ID) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

Table 12: US State Codes 

CREATE TABLE N30TCDUSS 

CD CHAR (2) NOT NULL. 

DESC CHAR (20) NOT NULL, 

PRIMARY KEY (CD) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

Table 13: ISO 3166 Country Codes 

CREATE TABLE N30TCD3166 
( 

CD CHAR (2) NOT NULL, 

DESC CHAR (20) NOT NULL, 

PRIMARY KEY (CD) . 
UNIQUE (DESC) 
) LOCK MODE ROW; 

Table 14: Contact Type Codes 

CREATE TABLE N30TCDCON 
( 

ID INTEGER NOT NXJLL, 

DESC CHAR (20) NOT NULL, 

PRI CHAR(l) NOT NULL CHECK (PRI IN CY', 'NM ) , 
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Table II: Industry Codes 
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PRIKARY KEY (ID) , 
UNIQUE <DESC) 
) LOCK MODE ROW; 

Tablets: Card Status 

CREATE TABLE N30TCDCKCS 
( 

ID INTEGER NOT NULL, 

DESC CHAR (20) NOT NULL, 
AUTH CHAR(l) NOT NULL, 

PRIMARY KEY (ID) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

Table 16: Credit Status 

CREATE TABLE N30TCDCHS 
( 

ID INTEGER NOT NULL, 

DESC CHAR(20) NOT NULL, 
AUTH CHAR(l) NOT NULL, 

PRIMARY KEY (ID) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

Tablet?: Credit Application 

CREATE TABLE N30TAPP 
( 

ID INTEGER NOT NULL, 

CH CHARACTER (1) , 

EMAIL CHARACTER (30) , 
FNAM CHARACTER (30) . 
LNAM CHARACTER (30), 
MNAM (niARACTER (30) , 
CPNAM CHARACTER (40), 
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PHO CHARACTER (20) . 

FAX CHARACTER (20) , 

ADRl CHARACTER (3 0) . 

ADR2 CHARACTER (30), 

ADR3 CHARACTER (3 0) , 

CTY CHARACTER (25) , 

ST CHARACTER (2) , 

ZIP CHARACTER (10) , 

CTRY CHARACTER ( 2 ) , 

BFNAM CHARACTER (30), 

BLNAM CHARACTER (30), 

BPHN CHARACTER (20), 

BADRl CHARACTER (30), 

BADR2 CHARACTER (30), 

BADR3 CHARACTER (30) , 

BCTY CHARACTER (25), 

BST CHARACTER (2) . 

BZIP CHARACTER(IO) , 

BCTRY CHARACTER ( 2 ) , 

OFF CHARACTER (30) . 

OPFT CHARACTER (30), 

CON CHARACTER (30) « 
CDINDIO INTEGER NOT NULL, 

DUNS CHARACTER (20), 

DBA CHARACTER (30), 

PCPY CHARACTER (30), 

TAXID CHARACTER(20) , 

ASLS CHARACTER (20), 

EDATE CHARACTER (20), 

LOGS CHARACTER (5) , 

EMPS CHARACTER ( 5 ) , 

TBUS CHARACTER ( 20 ) , 

BKNAM CHARACTER (30), 

BKCON CHARACTER (30). 

BKADR CHARACTER (40), 

BKCTY CHARACTER (25), 
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BKST CHARACTER ( 2 ) , 
BKZIP CHARACTER (10) , 
BKPHO CHARACTER (20), 
CKGNUM CHARACTER (20) , 
SAVNUM CHARACTER (20) , 
TRINAM CHARACTER (30) , 
TRIADR CHARACTER (40) , 
TRICTY CHARACTER (25) , 
TRIST CHARACTER (2) , 
TRIZIP CHARACTER (10) , 
TR2NAM CHARACTER (30) , 
TR2ADR CHARACTER (4 0) , 
TR2CTY CHARACTER (25) , 
TR2 ST CHARACTER ( 2 ) , 
TR2ZIP CHARACTER ( 10 ) , 
SGI CHARACTER (1) , 
S62 CHARACTER (1), 
APPDT DATSTIME YEAR TO SECOND, 
MAIL CHARACTER (1) , 
FINFO CHARACTER ( 1 ) , 
EINFO CHARACTER ( 1 ) . 
STAT CHARACTER (20). 
ACCID INTEGER. 
ACCGID INTEGER, 
LDT DATE, 
LAMT DECII4AL(14,2) . 
LSRC CHAR(25}. 
GFEE DECIMAL ( 8 . 4 ) , 
GCST CHAR (25) . 
ACCAID INTEGER. 
AFEE DECIMAL(8 .4). 
CNAMl CHAR (35), 
CNUMl CHAR(16). 
CNAM2 CHAROB) , 
CNUM2 CHAR (16), 
CNAM3 CHAR (35), 



{ account assigned or null } 

{ guarantor account } 

{ limit date ) 

{ limit amount ) 

{ limit source } 

{ guarantor fee } 

{ guarantor customer id ) 

{ association } 

{ association fee } 
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CNUM3 CHAR (16). 

SRC CHAR (25) NOT NULL. { source 
SNTDTTM DATETIME YEAR TO SECOND, 
RSPDTTM DATETIME YEAR TO SECOND. 

PRIMARY KEY (ID) 
) lock mode row; 



Table 18: NET30/Accounts 



CREATE TABLE N30TACC 



ZD INTEGER NOT NULL. 

TYP CHAR(l) NOT NULL. 

CDINDID INTEGER NOT NULL. 
TAXID CHAR (14). 
CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL. 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (15) NOT NULL, 
CHGUSRID CHAR (15) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL. 
CHGCLNT CHAR (15) NOT NULL, 



{ account id 

{ account type 

{ industry code 

{ federal tax id or vat } 

{ create user id 

( create datetime 

{ create server 

{ create client 

{ change by user 

{ change datetime 

{ change server 

{ change client 



PRIMARY KEY (ID) CONSTRMNT N3 0CACCPK. 

CHECK (TYP IN ( ' A' , ' C ' , ' F * , ' G • , ' I • , • M ' ) ) CONSTRAINT N30CACC1 
) LOCK MODE ROW; 



CRBATE TABLE N30TACCNAM 



Table 19: NET30/Accoune Names 



ID INTEGER NOT NULL, 

ACCID INTEGER NOT NULL. 

PRI CHAR(l) NOT NULL, 

NAN CHAR (100) NOT NULL. 



{ name id 
{ account id 
{ Y/N. N = DBA 
( name 
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CNAM CHAR (100) 

DEFAULT "NOT DONE" 

NOT NULL, {compress name } 



TODO: constraint to ma)ce sure there is one primary and zero or more non-primary. 
PRIMARY KEY (ID) CONSTRAINT N30CACCNAMPK, 

FOREIGN ICEY (ACCID) REFERENCES N30TACC (ID) CONSTRAINT N30ACCNAMFK1, 
CHECK (PRI IN CY', 'N')) CONSTRAINT N30ACCNAM1 
) LOCK MODE ROW; 

CREATE INDEX N30IACCNAM1 ON N30TACCNAM (NAM, ACCID) ; 
CREATE INDEX N30IACCNAM2 ON N30TACCNAM (CNAM) ; 

Table 20: NET30/Account Contacts 

CREATE TABLE N30TACCCON 

( 



ID 


INTEGER NOT NULL, 


{ contact id 


ACCID 


INTEGER NOT NULL, 


{ account ijcl 


CDCONID 


INTEGER NOT NULL, 


{ contact type 


LNN 


CHAR (25) , 


{ last name 


FNM 


CHAR(25) , 


{ first name 


MNM 


CHAR(25) , 


{ middle name 


JOB 


CHAR(40) , 


{ job title 


DPT 


CHAR(40) , 


{ department 


URL 


CHAR(IOO) , 


{ www url 


ENL 


CmR{80) , 


{ email address 


PHN 


CHAR(20) , 


{ voice phone 


FAX 


CHAR(2D) , 


{ fax number 


MBL 


CHAR(20) , 


{ mobile phone 


PGR 


CHAR(20) , 


{ pager number 


NTS 


CHAR(IOOO) , 


{ notes 


ATTN 


CHAR(40) , 


{ attn: line 


ADDRl 


CHAR(40) , 


{ address 1 


ADDR2 


CHAR(40) , 


{ address 2 


AODR3 


CHAR(40) , 


( address 3 


CTY 


CHAR(40} , 


{ city 


STCODID 


CHAR(2) , 


{ state code 
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ZIP CHAR(14) . {zip } 

CYCODZD CHAR (2), { country code } 



TODO: Need FK constraints on codes. 
PRIMARY KEY (ID) CONSTRAINT N30CACCCONPK, 

FOREIGN KEY (ACCID) REFERENCES N30TACC (ID) CONSTRAINT N30CACCCONFK1 

) LOCK MODE ROW; 

CREATE UNIQUE INDEX N30IACCCON ON N30TACCCON (ACCID, CDCONID) ; 

Table 21: NET30/Account Balances 

CREATE TABLE N30TACCBAL 
( 



ID 


INT8 NOT NULL, 


{ unique id 


) 


YR 


INTEGER NOT NULL, 


{ year, 2000 


• • ) 


PD 


INTEGER NOT NULL, 


{ period 


J 


ACCID 


INTEGER NOT NULL, 


{ account id 


) 


BBL 


MONEY (14,2) NOT NULL. 


{ current pd 


beg balance } 


EBL 


MONEY (14,2) NOT NULL. 


{ current /ending balance } 


CBBL 


MONEY (14,2) NOT NULL. 


{ pd beg auth balance } 


CEBL 


MONEY (14,2) NOT NULL. 


{ current/ending auth bal } 



PRIMARY KEY (ID) , 
UNIQUE (YR, PD, ACCID) , 

FOREIGN KEY (ACCID) REFERENCES N3 0TACC (ID) CONSTRAINT N30CACCBALFK1 
) LOCK MODE ROW; 



CREATE TABLE N30TACCAUD 



Table 22: NET30/Account Audit History 



ID INT8 NOT NULL, 

ACCID INTEGER NOT NULL, 

ATTR CHAR (20) NOT NULL. 

OVAL CHAR (20) NOT NULL, 

NVAL CHAR(20) NOT NULL. 



I id 

{ account number 
( attribute 
{ old value 
{ new value 



CRTUSRID CHAR (15) NOT NULL. 
CRTDTTM DATETIME 



{ create user id ) 
{ create datetiroe } 
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YEAR TO SECOND NOT NULL. 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (15) NOT NULL, 
CHGUSRID CHAR (15) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 
CHGCLNT CHAR (15) NOT NULL, 



{ create server ) 

{ create client ) 

( change by user } 

{ change date time } 

( change server ) 

( change client ) 



PRIMARY KEY (ID) CONSTRAINT N30CACCAUDPK, 

FOREIGN KEY (ACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCAUDFKr 
) LOCK MODE ROW; . 



Tabic 23: NCTaO/Merchant Account Master 



CREATE TABLE N30TACCM 



ID INTEGER NOT NULL, 

STDT DATE, 



( account id 



PRIMARY KEY (ID), 

FOREIGN KEY (ID) REFERENCES N30TACC(ID) 
) LOCK MODE ROW; 



CREATE TABLE N30TNTWRK 



Table 24: Networks 



ID INTEGER NOT NULL. 

NAM 'CHAR(20) NOT NULL, 

CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (15) NOT NULL, 
CHGUSRID CHAR (15) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 



{ unique id 

{ network name 

{ create user id 

{ create datetime 

{ create server 

{ create client 

( change by user 

{ change datetime 
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CHGSRVR CHAR<1S) NOT NULL, 
CH6CLNT CHAR (15) NOT NULL. 



( change server ) 
{ change client ) 
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PRIMARY KEY (ID) CONSTRAINT N30CNTWRKPK 
) LOCK MODE ROW; 



CREATE TABLE N30TACCMTRM 



Tabic 25: Merchant Terminals 



ID INTEGER NOT NULL, 

ACCMID INTEGER NOT NULL, 
NTWRKID INTEGER NOT NULL, 
TRMADDR CHAR (20) NOT NULL, 
ACT CHAR(l) NOT NULL, 



{ unique id 

{ merchant id 

{ network id 

{ terminal address 



CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (15) NOT NULL, 
CHGUSRID CHAR (15) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 
CHGCLNT CHAR (15) NOT NULL, 



{ create user id 
{ create datetime 

{ create server 
{ create client 
{ change by user 
{ change datetime 

{ change server 
{ change client 



PRIMARY KEY (ID) CONSTRAINT N3 OCACCMTRMPK, 
UNIQUE (NTWRKID, TRMADDR) CONSTRAINT N30CACCMTRM2 , 
FOREIGN KEY (ACCMID) REFERENCES N30TACCM (ID) , 
FOREIGN KEY (NTWRKID) REFERENCES N30TNTWRK (ID) 
) LOCK MODE ROW; 

Table 26: N£T30/Guarantor Account Master 

CREATE TABLE N30TACCG 
( 

ID INTEGER NOT NULL, ( account id ) 

MIN MONEY (14, 2) NOT NULL, 
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PRIMARY KEY (ID) , 

FOREIGN KEY (ID) REFERENCES N30TACC(ID) 
) LOCK MODE ROW; 

Table 27: NET30/As$ociation Account Master 

CREATE TABLE N30TACCA 
( 

ID INTEGER NOT NULL, { account id } 

SRC CHAR (20) NOT NULL, 

PRIMARY KEY (ID) , 

FOREIGN KEY (ID) REFERENCES N30TACC{IO) 
) LOCK MODE ROW; 

Tablc 28: NET30/Issucr Account Master 

CREATE TABLE N30TACCI 
( 

ID INTEGER NOT NULL, { account id } 

ATR CHAR (10) NOT NULL, 



PRIMARY KEY (ID) , 

FOREIGN KEY (ZD) REFERENCES N30TACC{ID) 
) LOCK MODE ROW; 



Table 29: NET30/Card Holder Account Master 

CREATE TABLE N30TACCCH 
( 

ID INTEGER NOT NULL, 

GACCID INTEGER NOT NULL, 
GCID CHAR (20), 
GFEE DECIMAL (6, 4) NOT NULL, 
CDCHSID INTEGER NOT NULL, 
AACCID INTEGER, 
AFEE DECIMAL (6, 4) , 
LAMT MONEY (14, 2) , 
LDT DATE, 



{ account id 

{ guarantor accid 

{ guarantor cust id 

{ guarantor fee % 
{ credit status 
( assoc acct id 

{ assoc fee % 
{ limit amt 
{ limit date 



) 



} 
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LSRC CHAR(20), { limit source } 

SRC CHAR(20). ( cr line source } 



PRIMARY KEY (ID) CONSTRAINT N30CACCCHPK, 

FOREIGN KEY (ID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCCHFK1 , 
FOREIGN KEY (GACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCCHFK2 , 
FOREIGN KEY (AACCID) REFERENCES N30TACC{ID) CONSTRAINT N30CACCCHFK3 
) LOCK MODE ROW; 

--CREATE UNIQUE INDEX N30IACCCH1 ON N30TACCCH (GACCID, GCID) ; 



Table 30: NCT30/Card Holder Cards 



CREATE TABLE N30TACCCHC 



ID INTEGER NOT NULL, 

CNUM INT8 NOT NULL, 
ACCID INTEGER NOT NULL, 
NM CHAR(50) NOT NULL, 

IDT DATE NOT NULL, 

EDT DATE NOT NULL, 

CDCHCSID INTEGER NOT NULL, 
PIN CHAR(15), 
ACCCHCBID INTEGER, 



{ card id) 
{ card number 
{ account id 
{ name on card 
{ issue date 
{ expire date 
{ card status 
{ pin code or null 

{ card batch or null ) 



PRIMARY KEY (ID) CONSTRAINT N3 OCACCCHCPK, 

FOREIGN KEY (ACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCCHCFK1 , 
UNIQUE (CNUM) CONSTRAINT N30CACCCHC3 
) LOCK MODE ROW; 

CREATE UNIQUE INDEX N3 0IACCCHC1 ON N3 0TACCCHC (ACCID, ID); 

Table 31: N£T30/Card Holder Credit Limit History 

CREATE TABLE N30TACCCHL 
( 

ID INT8 NOT NULL. {unique id } 

ACCID INTEGER NOT NULL, { account id } 

LAMT MONEY (14, 2), { limit amt } 

LDT DATE. ( limit date ) 

LSRC CHAR (20), { limit source } 
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CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL. 
CRTCLNT CHAR (15) NOT NULL. 
CHGUSRID CHARdS) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 
CHGCLNT CHAR (15) NOT NULL, 



{ create user id 
{ create datetime 

( create server 
{ create client 
{ change by user 
{ change datetime 

{ change server 
{ change client 



PRIMARY KEY (ID) CONSTRAINT N30CACCCHLPK, 

FOREIGN KEY (ACCID) REFERENCES N30TACC(ID) CONSTRAINT N3 0CACCCHLFK1 
) LOCK MODE ROW; 

Table 32: N£T30/Card Holder Authorization Attempts 
(Logs failed or successful attempt to authorize against a card. Only APPROVED authorizations make it into the transaction table) 

CREATE TABLE N30TACCCHA 

( 



ID 


INT8 NOT NXn^L, 


{ AUTH id ) 


ACCCHID 


INTEGER, 


{ card holder } 


ACCCHCID 


INTEGER « 


{ card } 


CNUM 


CHAR (16) , 


{ card number entered ) 


ACCMID 


INTEGER NOT NULL. 


{ merchant maybe invalid 


DOC 


CHAR(20) , 


{ po, inv, etc ) 


DTTM 


DATETIME 


{ actual date/time } 




YEAR TO SECOND NOT NULL, 




CDRSPID 


INTEGER NOT NULL, 


{ auth response ) 


ACCTRNID 


INT8 NOT NULL, 


{auth tran id } 


CRBAL 


MONEY(14,2) , 


{avail cr } 


NAM 


CHAR(35) , 


{ name on card } 


EXP 


CHAR(IO) , 


{ expiration given } 



CRTUSRID 
CRTDTTM 



CRTSRVR 



CHARdS) NOT NULL, { create user id } 

DATETIME { create datetime } 
YEAR TO SECOND NOT NULL. 

CHARdS) NOT NULL, { create server } 
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CRTCLNT CHAR (15) NOT NULL, 

CHGU5RID CHAR (15) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 

CHGCLNT CHAR (15) NOT NULL, 



{ create client ) 

( change by user } 

{ change date time } 

{ change server ) 

{ change client } 



PRIMARY KEY (ID) CONSTRAINT N30CACCCHAPK 
) LOCK MODE ROW; 



Table 33: NET30/Account Transaction Master Table 
(Describes a single authorization, invoice receipt, payment receipt, merchant check, promotional; balance adjustment, etc.) 

CREATE TABLE N30TACCTRN 



ID INTB NOT NULL, 

CDTRNID INTEGER NOT NULL, 

YR INTEGER NOT NULL, 

PD INTEGER NOT NULL, 

GRP INT8 NOT NULL, 

ACCCHID INTEGER NOT NULL, 

ACCCHCID INTEGER NOT NULL, 

ACCMID INTEGER NOT NULL, 

AMT M0NEY(14,2) NOT NULL, 

DOC CHAR(20), 

DTTM DATETIME 

YEAR TO SECOND NOT NULL, 

CDPMTID INTEGER NOT NULL, 

ACCGSLID INT8 , 



( tran id } 

{ transaction type ) 

{ year } 

{ period } 

{ group id 

{ card holder 

{ card 

{ merchant 

{ amount 

{ po, inv, chk#, etc 
{ actual date/time 

{ terms 

{ sales batch id 



CRTUSRID CHARdS) NOT NULL, 
CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (15) NOT NULL, 
CHGUSRID CHARdS) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NtJLL, 



{ create user id } 

( create datetime } 

{ create server ) 

( create client ) 

{ change by user } 

{ change datetime } 
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CHGSRVR CHAR (15) NOT NULL, 
CHGCLNT CHAR (15) NOT NULL, 



{ change server ) 
{ change client } 
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PRIMARY KEY (ID) CONSTRAINT N30CACCTRNPK 
) LOCK MODE ROW; 

CREATE INDEX N30IACCTRN1 ON N30TACCTRN (CRTDTTM. CDTRNID) ; 

Table 34: NET30/Accounr Transaction Detail 

CREATE TABLE N30TACCTRND 
( 

ID INT8 NOT NULL, { tran id } 

YR INTEGER NOT NULL, { year } 

PD INTEGER NOT NULL, { period ) 

ACCID INTEGER NOT NULL, { account id } 

ACCTRNID INT8 NOT NULL, {par en tran } 

CDTRNDID INTEGER NOT NULL, {tran type } 

DTTM DATETIME { tran time stamp } 

YEAR TO SECOND NOT NULL, 
AMT MONEY (14,2) NOT NULL, { tran amount } 

EBL MONEY (14,2) NOT NULL, { new bal amount } 

CEBL MONEY (14,2) NOT NULL, { new cr baX amt ) 

STMT INT8 NOT NULL, ( statement id } 



CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (15) NOT NULL, 
CHGUSRID CHAR (15) NOT NXJLL. 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 
CHGCLNT CHAR (15) NOT NULL, 



I create user Id 

{ create datetime 

{ create server 

{ create client 

{ change by user 

{ change datetime 

{ change server 

{ change client 



PRIMARY KEY (ID) CONSTRAINT N30CACCTRNDPK, 

FOREIGN KEY (ACCTRNID) REFERENCES N30TACCTRN(ID) CONSTRAINT N3 OCACCTRNDFKl 
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) LOCK MODE ROW; 



CREATE TABLE N30TACCS 



Table 35: 



ID INT8 NOT NULL, 

ACCSBID INTEGER NOT NXJLL, 

FRDT DATE NOT NULL, 

THDT DATE NOT NULL. 

ACCID INTEGER NOT NULL, 

BBL MONEY (14, 2) NOT NULL, 

CBS MONEY (14, 2) NOT NULL, 

EBL MONEY (14,2) NOT NULL , 

CEBL MONEY (14, 2) NOT NULL, 

LAMT MONEY (14, 2), 

AVL MONEY (14, 2), 



( stmt id 

{ stmt batch id 

{ from date 

{ through date 

{ account id 

{ beg bal 

{ beg cr bal 

{ end bal 

{ end cr bal 

{ cr limit if ch 

{ available cr bal 



CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL. 
CRTSRVR CHAR (15) NOT NULL, 

CRTCLNT CHAR (15) NOT NULL, 

CHGUSRID CHAR (15) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 

CHGCLNT CHAR (15) NOT NULL, 



{ create user id 

( create datetime 

{ create server 

{ create client 

{ change by user 

{ change datetime 

{ change server 

{ change client 



PRIMARY KEY (ID) CONSTRAINT N30CACCSPK, 

FOREIGN KEY(ACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCSFK1 
) LOCK MODE ROW; 



VIEW: NET30/Card Holder Fees 

CREATE VIEW N30VACCCH1 
AS 

SELECT ID, GACCID, GFEE, AACCID, AFBE 
FROM N30TACCCH; 
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VIEW: NEmO/Transaction Detail Statement 

create view n30vacctrndl as 
select 

det.yr, det.pd, det.accid, det .acctrnld, det.id, det.dttm, 
det.amt as damt, det.ebl, det.cebl, ddsc.desc as ddesc, det.stmt* 
ddsc . bad j « ddsc . cad j . 

chnam.nam as chnanir crd.cnum, memam.nam as mernam, trn.amt as tamt, trn.doc, 
tm.dttm as tdttm, tdsc.desc as tdesc 

from 

n30tacctrnd as det» 
n30tcdtrnd as ddsc. 
n30tacctrn as trn, 
n30tcdtrn as tdsc, 
outer n30taccnam as chnam, 
outer naotaccnam as mernam, 
outer nBOtaccchc as crd 
where 

det , cdtrndid = ddsc. id 
and det.acctrnid = trn.id 
and trn.cdtrnid = tdsc. id 

and trn.accchid = chnam.accid and chnam.pri = 'Y' 
and trn.accmid = mernam . accid and mernam. pri = 'Y» 
and trn.accchcid = crd. id 



Table 36: Guarantor Sales Batch 



CREATE TABLE N30TACCGSL 



ID INT8 NOT NULL. 

ACCGID INTEGER NOT NULL, 

SIZ INTEGER NOT NULL, 

CRB CHAR(l) 

CHECK (CRB IN ( 'Y' , 'N*)), 
TXDTTM DATETIME 

YEAR TO SECOND, 
CRTUSRID CHAR (15) NOT NULL, { create user id } 

CRTDTTM DATETIME { create date time } 



{ UNIQUE ID ) 

{ GUARANTOR ACCOUNT ID } 

{ DETAIL ITEM COUNT . ) 

{ credit/debit batch ) 

{ TRANSMIT DATETIME ) 
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YEAR TO SECOND NOT NULL. 

CRTSRVR CHAR (15) NOT NULL, { create server ) 

CRTCLNT CHAR (15) NOT NULL. { create client } 

CHGUSRID CHAR (15) NOT NULL, { change by user ) 

CHGDTTM DATBTIME { change datetime ) 

YEAR TO SECOND NOT NULL, 

CHGSRVR CHAR (15) NOT NULL, { change server ) 

CHGCLNT CHAR (15) NOT NULL, { change client ) 

PRIMARY KEY (ID) CONSTRAINT N3 OCACCGSLPK, 

FOREIGN KEY{ACCGID) REFERENCES N30TACCG(ID) CONSTRAINT N30CACCGSLFK1 

); 

Table 97: Card Batch Statuses 

CREATE TABLE N30TCDCHCB 
( 

ID INTEGER NOT NULL, 

DESC CHAR (20) NOT NULL, 



PRIMARY KEY (ID) , 
. UNIQUE (DESC) 
) LOCK MODE ROW; 

CREATE TABLE N30TACCCHCB 



Table 38: Card Printing/Embossing Batches 



ID INTEGER NOT NULL, 

COCHCBID INTEGER NOT NULL, 
CNT INTEGER NOT NULL, 

SELDTTM DATETIME 

YEAR TO SECOND, 
RCVDTTM DATETIME 

YEAR TO SECOND, 
CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 



{ unique id ) 
( batch status ) 
{ number of cards ) 
{ select timestamp } 

{ receiv timestamp } 

( create user id } 
( create datetime } 

{ create server ) 
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CRTCLNT CHAR (15) NOT NULL. 

CKGUSRID CHAR (15) NOT NULL. 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL. 

CHGCLNT CHAR (15) NOT NULL, 



{ create client } 

{ change by user } 

{ change datetime } 

{ change server } 

{ change client ) 



PRIMARY KEY (ID) CONSTRAINT N30CACCCHCBPK 



) LOCK MODE ROW; 

Table 39: Card Holder Application 

CREATE TABLE N30TAPPCH 
( 

ID INTEGER NOT NULL. 



FNAM CHARACTER (30) NOT NULL. 

LNAM CHARACTER (30) NOT NULL. 

MNAM CHARACTER (30) . 

CPNAM CHARACTER (4 0) NOT NULL. 

ADRl CHARACTER (30) NOT NULL. 

ADR2 CHARACTER (30), 

ADR3 CHARACTER (30), 

CTY CHARACTER (25) NOT NULL. 

ST CHARACTER (2) NOT NULL. 

ZIP CHARACTER (10) NOT NULL, 

CTRY CHARACTER ( 2 ) , 

PHO CHARACTER (20) NOT NULL, 

FAX CHARACTER ( 20 ) . 

EMAIL CHARACTER (30). 

BADRl CHARACTER (30) NOT NULL. 

BADR2 CHARACTER (30). 

BADR3 CHARACTER (30). 

BCTY CHARACTBR(25) NOT NULL, 

BST CHARACTER (2) NOT NULL. 

BZIP CHARACTERdO) NOT NULL. 

BCTRY CHARACTER ( 2 ) , 
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OFF CHARACTER (30) NOT NULL. 

OFFT CHARACTER (30) NOT NULL. 

CON CHARACTER (30) NOT NULL. 

CONT CHARACTER(30) NOT NOLL. 

CDINDID INTEGER NOT NULL, 

LOGS INTEGER NOT NULL. 

DUNS CHARACTER (20), 

DBA CHARACTER (30) , 

PCPY CHARACTER (30), 

TAXID CHARACTER (20 ) , 

ASLS INTEGER NOT NULL, 

EDATE CHARACTER (20) NOT NULL, 

EMPS INTEGER NOT NULL. 

CNAMl CHARACTER (35) NOT NULL, 

CNUMl CHARACTER ( 16 ) . 

CNAM2 CHARACTER (35) . 

CNUM2 CHARACTER ( 16 ) , 

CNAM3 CHARACTER (35) . 

CNUM3 CHARACTER ( 16 ) . 

BKNAM CHARACTER (30) . 

BKCON CHARACTER (30) , 

BKADR CHARACTER (40 ) . 

CKGNUM CHARACTER (20). 

BKCTY CHARACTER (25). 

BKST CHARACTER (2) , 

BKZIP CHARACTER(IO) . 

BKPHO CHARACTER (20). 

BKCTRY CHARACTER ( 2 ) . 

SAVNUM CHARACTER (20). 

BINAM CHARACTER (30) . 

BIPHN CHARACTER (20) . 

BlADRl CHARACTER (30), 

B1ADR2 CHARACTER (30), 

B 1ADR3 CHARACTER (30), 

BICTY CHARACTER (25) , 

BIST CHARACTER (2 ) . 
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BIZIP 

BICTRY 

B2NAM 

B2PHN 

B2ADR1 

B2ADR2 

B2AOR3 

B2CTY 

B2ST 

B2ZIP 

B2CTRY 

SIGl 

APPDT 

CDAST 

ACCCHID 

ACCGID 

LDT 

LAMT 

LSRC 

GFEE 

GCST 

ACCAID 

AFEE 

SRC 

SNTDTTM 
RSPDTTM 
CRTUSRID 
CRTDTTM 

CRTSRVR 
CRTCLNT 
CHGUSRID 
CHGDTTM 

CHGSRVR 
CHGCLNT 
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CHARACTER (10) , 
CHARACTER (2) . 
CHARACTER (30) , 
CHARACTER (20) , 
CHARACTER (30) , 
CHARACTER (30) . 
CHARACTER (30) . 
CHARACTER (25) , 
CHARACTER (2) , 
CHARACTER (10) , 
CHARACTER (2) . 

CHARACTER(l) NOT NOLL CHECK (SIGl IN ('Y'. 'N')), 
DATETIME YEAR TO SECOND, 
INTEGER NOT NULL, 

INTEGER, { account assigned or null } 

INTEGER, { guarantor account ) 

DATE, { limit date } 

DECIMAL ( 14 , 2 ) , { limit amount } 

CHARACTER ( 25 ) . { limit source ) 

DECIMAL (8, 4), { guarantor fee ) 

CHARACTER ( 25 ) , { guarantor customer id ) 

INTEGER, { association } 

DECIMAL (8 ,4), { association fee } 

CHARACTER (25) NOT NULL, { source } 

DATETIME YEAR TO SECOND, 

DATETIME YEAR TO SECOND, 

CHAR (15) NOT NULL, { create user id } 

DATETIME { create datetime } 
YEAR TO SECOND NOT NULL, 

CHARACTER (15) NOT NULL, { create server } 
CHARACTER (15) NOT NULL, { create client } 
CHARACTER (15) NOT NULL, { change by user ) 
DATETIME { change datetime ) 
YEAR TO SECOND NOT NULL, 

CHARACTER (15) NOT NULL, { change server } 
CHARACTER (IS) NOT NULL, { change client } 
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PRIMARY KEY (ID) 
) lock mode row; 

Tabic 40: Merchant Agreement 

CREATE TABLE N30TAPPM 
( 

ID INTEGER NOT NULL, 



CPNAM CHARACTER (40) NOT NULL, 

ADRl CHARACTER (30) NOT NULL, 

ADR2 CHARACTER (30) , 

ADR3 CHARACTER (30) , 

CTY CHARACTER (25) NOT NULL, 

ST CHARACTER (2) NOT NULL, 

ZIP CHARACTER (10) NOT NULL, 

CTRY CHARACTER ( 2 ) , 

PHO CHARACTER (20) NOT NULL, 

FAX CHARACTER (20) « 

MADRl CHARACTER (30), 

MADR2 CHARACTER (30) , 

MADR3 CHARACTER (30) , 

MCTY CHARACTER (25), 

MST CHARACTER (2 ) , 

MZIP CHARACTER ( 10 ) , 

MCTRY CHARACTER ( 2 ) , 

TAXID CHARACTER { 20) , 

CDINDID INTEGER NOT NULL. 

PFNAM CHARACTER (3 0) NOT NULL, 

PLNAM CHARACTER (30) NOT NULL, 

PMNAM CHARACTER (30) , 

PADRl CHARACTER (30), 

PADR2 CHARACTER (30), 

PADR3 CHARACTTER (30), 

PCTY CHARACTER (25), 

PST CHARACTER (2) , 

PZIP CHARACTER ( 10 ) , 
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PCTRY CHARACTER ( 2 ) . 

PPHO CHARACTER (20), 

PBMAIL CHARACTER (30), 

AFNAM CHARACTER (30) , 

ALNAM CHARACTER (30) , 

AADRl CHARACTER (30 ) . 

AADR2 CHARACTER (30), 

AADR3 CHARACTER (30), 

ACTY CHARACTER ( 25 ) , 

AST CHARACTER (2) , 

AZIP CHARACTER ( 10 ) . 

ACTRY CHARACTER ( 2 ) , 

APHO CHARACTER (20), 

SIGl CHARACTER(l) NOT NULL CHECK (SIGl IN ('Y', 'N')), 

SRC CHARACTER (25) NOT NULL, { source } 

APPDT DATETIME YEAR TO SECOND, 

COAST INTEGER NOT NULL, 

ACCMID INTEGER, { account assigned or null } 

CRTUSRID CHAR (15) NOT NULL, { create user id } 

CRTDTTM DATETIME { create datetlme } 

YEAR TO SECOND NOT NULL, 

CRTSRVR CHAR (15) NOT NULL. { create server ) 

CRTCLNT CHAR (15) NOT NULL, { create client ) 

CHGUSRID CHAR (15) NOT NULL, { change by user } 

CHGDTTM DATETIME { change datetlme } 

YEAR TO SECOND NOT NULL, 

CHGSRVR CHAR (15) NOT mLh, { change server } 

CHGCLNT CHAR (15) NOT NULL, { change client } 



PRIMARY KEY (ID) 
) locl( mode row; 

Tabic 41: NET30/Card Holder Line Request Statuses 

CREATE TABLE N30TCDCHLRS 
( 

ID INTEGER NOT NULL, 
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OESC CHAR (20) NOT NULL* 



PRIMARY KEY (ID) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

CREATE TABLE N30TACCCHLR 



Table 42: NET30/Card Holder Line Requests 



ID INTB NOT NULL, 

ACCGID INTEGER NOT NULL, 
ACCCHID INTEGER NOT NULL, 
RQAMT DECIMAL (14, 2) NOT NULL, 
SNTDTTM DATETIME YEAR TO SECOND, 
RSPDTTM DATETIME YEAR TO SECOND, 
RSPAMT DECIMAL (14,2), 
CDCHLRSID INTEGER, 



{ request id} 

{ guarantor } 

{ card holder id ) 

{ requested amount, possibly zero } 

{ timestamp sent to guarantor ) 

{ timestamp received from guarantor } 

{ amount approved } 

{ response code from guarantor - our own code } 



PRIMARY KEY (ID) CONSTRAINT N3 OCACCCHLRPK, 

FOREIGN KEY (ACCGID) REFERENCES N30TACCG(ID) CONSTRAINT N30CACCCHLRFK1 , 
FOREIGN KEY (ACCCHID) REFERENCES N30TACCCH (ID) CONSTRAINT N3 0CACCCHLRFK2 , 
FOREIGN KEY (CDCHLRSID) REFERENCES N30TCDCHLRS (ID) CONSTRAINT N30CACCCHLRFK3 
) LOCK MODE ROW; 

Table 43: References 

CREATE TABLE N30TACCREF 
( 

ID INTEGER NOT NULL, 
ACCID INTEGER NOT NULL, 



LOCS INTEGER NOT NULL, 

DUNS CHARACTER (20), 

PCPY CHARACTER (30), 

ASLS INTEGER NOT NULL, 

EDATE CHARACTER (20) NOT NULL, 

EMPS INTEGER NOT NULL, 

BKNAM CHARACTER (30), 

BKCON CHARACTER (30). 
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BKADR CHARACTER(40) , 

CKGNUM CHARACTER ( 20 ) , 

BKCTY CHARACTER < 2 5 ) , 

BKST CHARACTER (2 ) , 

BKZIP CHARACTER (10) , 

BKPHO CHARACTER (20), 

BKCTRY CHARACTER (2 ) , 

S AVNUM CHARACTER (20), 

BINAM CHARACTER (30) , 

BIPHN CHARACTER (20) , 

BlADRl CHARACTER (30), 

B1ADR2 CHARACTER (30), 

B1ADR3 CHARACTER (30), 

BICTY CHARACTER (25) , 

BIST CHARACTER ( 2 ) , 

B12IP CHARACTER (10) , 

BICTRY CHARACTER ( 2 ) , 

B2NAM CHARACTER (30) , 

B2PHN CHARACTER (20) , 

B2 ADRl CHARACTER (30), 

B2ADR2 CHARACTER (30), 

B2ADR3 CHARACTER (30), 

B2CTY CHARACTER (25), 

B2ST CHARACTER (2) , 

B2ZIP CHARACTER ( 10 ) , 

B2CTRY CHARACTER (2) , 

CRTUSRID CHAR (15) NOT NULL, { create user id } 

CRTDTTM DATETIME { create datetitne } 

YEAR TO SECOND NOT NULL, 

CRTSRVR CHARACTER (15) NOT NULL, { create server ) 

CRTCLNT CHARACTER (15) NOT NULL, { create client } 

CHGUSRIO CHARACTER (15) NOT NULL, { change by user ) 

CHGDTTM DATETIME { change date time ) 

YEAR TO SECOND NOT NULL, 

CHGSRVR CHARACTER (15) NOT NULL, { change server } 

CHGCLNT CHARACTER (15) NOT NULL, { change client ) 
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PRIMARY KEY (ID) CONSTRAINT N30CACCREFPK, 

FOREIGN KEY (ACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCREFFK1 
} lock mode row; 

Table 44: 

CREATE TABLE N30TACCSB 



ID INTEGER NOT NULL, 

PRTDT DATE, 

THDT DATE NOT NULL, { through date 

CRTUSRID CHAR (15) NOT NULL, { create user id ) 

CRTDTTM DATETIME { create datetime } 

YEAR TO SECOND NOT NULL, 

CRTSRVR CHARACTER (15) NOT NULL, { create server } 

CRTCLNT CHARACTER (15) NOT NULL, { create client } 

CHGUSRID CHARACTER (IS) NOT NULL, { change by user } 

CHGDTTM DATETIME { change datetime } 

YEAR TO SECOND NOT NULL, 

CHGSRVR CHARACTER (IS) NOT NULL, { change server } 

CHGCLNT CHARACTER (15) NOT NULL, { change client ) 



PRIMARY KEY (ID) CONSTRAINT N30CACCSBPK 
} lock mode row; 

VIEW: NET30/Card Holder Line Requests 
•CREATE VIEW N30VACCCHLR1 (ID, ACCCHID) 
AS 

SELECT MAX (ID) , ACCCHID 
FROM 

N30TACCCHLR 
GROUP BY 
ACCCHID; 

Expand SYSTID.NM 

ALTER TABLE SYSTID MODIFY NM CHAR(20); 

Table 45: Sales Status 
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CREATE TABLE N30TCDSLSST 
( 

ID INTEGER DEFAULT 10 NOT NULL, 

DESC CHAR (30) NOT NULL, 



PRIMARY KEY (ID) CONSTRAINT N30CCDSLSSTPK, 
UNIQUE (DESC) CONSTRAINT N30CCOSLSST1 
) LOCK MODS ROW; 

INSERT INTO SYSTID (NM, LSTID) VALUES ( "N30TCDSLSST" . 30); 



INSERT INTO N30TCDSLSST (ID, DESC) VALUES (10, "New Lead") ; 

INSERT INTO N30TCDSLSST (ID, DESC) VALUES (20, "Waiting on Agreement"); 

INSERT INTO N30TCDSLSST (ID. DESC) VALUES (30, "Mail Agreement"); 

INSERT INTO N30TCDSLSST (ID, DESC) VALUES (40, "See At Sliow"); 

INSERT INTO N30TCDSLSST (ID, DESC) VALUES (SO, "Need decision ma)cer'*) ; 

INSERT INTO N30TCDSLSST (ID, DESC) VALUES (60, "Not Interested"); 

INSERT INTO N3 0TCDSLSST (ID. DESC) VALUES (70, "No Answer"); 

INSERT INTO N30TCDSLSST (ID, DESC) VALUES (80, "Other"); 

Table 46: Agreement Status 

CREATE TABLE N30TCDAGST 
( 

ID INTEGER DEFAULT 4 0 NOT NULL. 

DESC CHAR(30) NOT NULL, 



PRIMARY KEY (ID) CONSTRAINT N30CCDAGSTPK, 
UNIQUE (DESC) CONSTRAINT N30CCDAGST1 
) LOCK MODE ROW; 

INSERT INTO SYSTID (NM, LSTID) VALUES ( "N30TCDAGST" , 30); 



INSERT INTO N30TCDAGST (ID, 

INSERT INTO N30TCDAGST (ID, 

INSERT INTO N30TCDAGST (ID, 

INSERT INTO N30TCDAGST (ID, 



DESC ) VALUES (10, " Faxed " ) ; 

DESC) VALUES (20, "Mailed"); 

DESC) VALUES (30, "Complete"); 

DESC) VALUES (40, "Not Sent"); 

Table 47: App Status Reason 
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CREATB TABLE N30TCDASTR 
{ 

ID INTEGER NOT NULL, 

DESC CHAR (30) NOT NULL, 

PRIMARY KEY (ID) CONSTRAINT N30CCDASTRPK, 
UNIQUE (DESC) CONSTRAINT N30CCDASTR1 
) LOCK MODE ROW; 

INSERT INTO SYSTID (NM, LSTID) VALUES ( "NSOTCDASTR" , 30); 

INSERT INTO N3 0TCDASTR (ID. DESC) VALUES (10, "Not interested"); 
INSERT INTO N30TCDASTR (ID, DESC) VALUES (20, »NO such company"); 
INSERT INTO N30TCDASTR (ID, DESC) VALUES (30, ••Duplicate"); 

{ 

NEW statuses FOR apps 

} 



INSERT 


INTO 


N30TCDAST 


(ID. 


DESC) 


VALUES 


(5, 


••Data quality waiting^*); 


INSEFET 


INTO 


N30TCDAST 


(ID, 


DESC) 


VALUES 


(6, 


•* Sales waiting") ; 


INSERT 


INTO 


N30TCDAST 


(ID, 


DESC) 


VALUES 


(7, 


••In process") ; 


INSERT 


INTO 


N30TCDAST 


(ID, 


DESC) 


VALUES 


(8, 


"Suspended") ; 












NEW statuses FOR apps 


INSERT 


INTO 


N30TCDAST 


(ID. 


DESC) 


VALUES 


(5. 


"Data quality waiting"); 


INSERT 


INTO 


N30TCDAST 


(ID, 


DESC) 


VALUES 


(6, 


"Sales waiting^'); 


INSERT 


INTO 


N30TCDAST 


(ID, 


DESC) 


VALUES 


(7. 


"In process" ) ; 


INSERT 


INTO 


N30TCDAST 


(ID, 


DESC) 


VALUES 


(8. 


"Suspended" ) ; 



Card Holder Changes 

ALTER TABLE N30TAPPCH ADD NTS TEXT; { Comments ) 

ALTER TABLE N30TAPPCH ADD CDSLSSTID INTEGER; { Sales Status } 

ALTER TABLE N30TAPPCH ADD CONSTRAINT 

FOREIGN KEY (CDSLSSTID) REFERENCES N30TCDSLSST (ID) CONSTPAINT N30CAPPCHFK1; 

ALTER TABLE N30TAPPCH ADD CDAGSTID INTEGER; { Agreement Status } 

ALTER TABLE N30TAPPCH ADD CONSTRAINT 
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FOREIGN KEY (CDA6STID) REFERENCES N30TCDAGST (ID) CONSTRAINT N30CAPPCHFK2 ; 

ALTER TABLE N3 0TAPPCH ADD CDASTRID INTEGER; { App Status Reason ) 
ALTER TABLE N30TAPPCH ADD CONSTRAINT 

FOREIGN KEY (CDASTRID) REFERENCES N30TCDASTR (ID) CONSTRAINT N3 0CAPPCHFK3 ; 

ALTER TABLE N30TAPPCH ADD AGNUSRID INTEGER; { agent systusr.id working ) 

ALTER TABLE N30TAPPCH ADD CONSTRAINT 

FOREIGN KEY (AGNUSRID) REFERENCES SYSTUSR(ID) CONSTRAINT N30CAPPCHFK4 ; 

ALTER TABLE N30TAPPCH ADD SUSDTTM DATETIME { suspense until datetime } 

YEAR TO SECOND; 
ALTER TABLE N30TAPPCH ADD TOPLEAD CHAR(l) DEFAULT 'N' 

NOT NULL CHECK (TOPLEAD IN ( ' Y' , 'N' ) ) ; ( Top Lead Flag } 

Merchant Changes 

ALTER TABLE N30TAPPM ADD NTS TEXT; { Comments 

ALTER TABLE N3 0TAPPM ADD CDSLSSTID INTEGER; { Sales Status } 

ALTER TABLE N3 0TAPPM ADD CONSTRAINT 

FOREIGN KEY (CDSLSSTID) REFERENCES N30TCDSLSST (ID) CONSTRAINT N30CAPPMFK1; 

ALTER TABLE N30TAPPM ADD CDAGSTID INTEGER; { Agreement Status } 

ALTER TABLE N30TAPPM ADD CONSTRAINT 

FOREIGN KEY (CDAGSTID) REFERENCES N30TCDAGST (ID) CONSTRAINT N30CAPPMFK2; 

ALTER TABLE N30TAPPM ADD CDASTRID INTEGER; { app Status Reason ) 

ALTER TABLE N30TAPPM ADD CONSTRAINT 

FOREIGN KEY (CDASTRID) REFERENCES N30TCDASTR (ID) CONSTRAINT N30CAPPMFK3; 

ALTER TABLE N30TAPPM ADD AGNUSRID INTEGER; ( agent systusr.id working ) 

ALTER TABLE N30TAPFM ADD CONSTRAINT 

FOREIGN KEY (AGNUSRID) REFERENCES SYSTUSR(ID) CONSTRAINT N30CAPPMFK4 ; 

ALTER TABLE N30TAPPM ADD SUSDTTM DATETIME { suspense until datetime } 

YEAR TO SECOND; 
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ALTSR TABLE N30TAPPM ADD TOPLBAD CHAR(l) DEFAULT >N> 

NOT NULL CHECK (TOPLEAD IN 'N')); { Top Lead Flag 

Table 48: Saks History 

CREATE TABLE N30TSAHIST 

ID INTEGER NOT NULL, 

AGNUSRID INTEGER NOT NULL, 
CALLDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
APPID INTEGER NOT NULL, 
CALLTIME INTEGER NOT NULL, 
CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (15) NOT NULL, 
CHGUSRID CMARdS) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CH6SRVR CKARdS) NOT NULL, 
CHGCLNT CHAR (15) NOT NULL, 
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{ agents user id ) 

{ call date time 

( application id 
( call time in seconds } 

{ create user id 
( create date time 

{ create server 
( create client 
( change by user 
{ change date time 

{ change server 
{ change client 



PRIMARY KEY (ID) CONSTRAINT N30CSAHISTPK, 
FOREIGN KEY (AGNUSRID) REFERENCES SYSTUSR(ID) CONSTRAINT N30CSAHISTFK1 
} LOCK MODE ROW; 

INSERT INTO SYSTID (NM, LSTID) VALUES ( "NBOTSAHIST" , 1000); 



Table 49: Sales Scripts 



CREATE TABLE N30T5ASCRP 
( 

ID INTEGER NOT NULL, 
NM CHAR (30) NOT NULL, 
SCRP TEXT NOT NULL, 
CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIME 



( script id 
{ script name 
{ script 
{ create user id 
{ create date time 



{ id 
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10 



15 



YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (15) NOT NULL, 
CHGUSRID CHAR(15) NOT NULL. 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 
CHGCLNT CHAR (15) NOT NULL, 



{ create sexrver 

{ create client 

{ change by user 

{ change date time 

( change server 

{ change client 



20 



25 



30 



35 



40 



45 



50 



55 



60 



PRIMARY KEY (ID) CONSTRAINT N30CSASCRPPK 
) LOCK MODE ROW; 

INSERT INTO SYSTID (NM, LSTID) VALUES ( "NSOTSASCRP" , 1000); 

Table 50: Script Relationships 



CREATE TABLE N3 OTSASCRPREL 
( 

ID INTEGER NOT NULL, 

) 

PSASCRPID INTEGER NOT NULL, 
CSASCRPID INTEGER NOT NULL, 

CRTUSRID CHARdS) NOT NULL, 
CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHARdS) NOT NULL, 
CRTCLNT CHARdS) NOT NULL, 
CHGUSRID CHARdS) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHARdS) NOT NULL, 
CHGCLNT CHARdS) NOT NULL, 



{ parent script id 

{ child script id 

{ create user id 

{ create date time 

( create server 

{ create client 

{ change by user 

{ change date time 

{ change server 

{ change client 



{ id 



65 



70 



PRIMARY KEY (ID) CONSTRAINT N30CSASCRPRELPK, 
FOREIGN KEY (PSASCRPID) REFERENCES N30TSASCRP (ID) CONSTRAINT N30CSASCRPRELFK1, 
FOREIGN KEY (CSASCRPID) REFERENCES N30TSASCRP (ID) CONSTRAINT N3 0CSASCRPRELFK2 
) LOCK MODE ROW; 

INSERT INTO SYSTID (NM, LSTID) VALUES ( •'N3 OTSASCRPREL " , 1000); 
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Table 51: Sales 

CREATE TABLE N30TSAQ 
( 

ID INTEGER NOT NULL. 
TYPE CHAR(l) NOT NULL, 

) 

DESC CHAR (80) NOT NULL, 
SQL CHAR (300) NOT NULL, 

) 

SASCRPID INTEGER. 

CRTUSRID CHAR (15) NOT NULL, 

CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (IS) NOT NULL, 
CHGUSRID CHAR (15) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CmGSRVR CHTUldS) NOT NULL, 
CHGCLNT CHAR (15) NOT NULL, 



Queue 



{ queue id } 

{ 'M» Merchant, 'C Cardholder 

{ description } 

{ sql statement 

{ script for this queue } 

{ create user id ) 

{ create date time } 

{ create server ) 

{ create client } 

{ change by user } 

{ change date time ) 

{ change server ) 

{ change client } 



PRIMARY KEY (ID) CONSTRAINT N30CSAQPK. 
FOREIGN KEY (SASCRPID) REFERENCES N30TSASCRP (ID) CONSTRAINT N30CSAQFK1, 
CHECK (TYPE IN ('M'. 'C')) CONSTRAINT N30CSAQ1 
) LOCK MODE ROW; 

INSERT INTO SYSTID (NM, LSTID) VALUES ("N30TSAQ", 1000); 



Table 52: Sales Agent Assignment 



CREATE TABLE N30TSAASGN 



ID INTEGER NOT NULL, 

AGNUSRID INTEGER NOT NULL, 
SEQ INTEGER NOT NULL, 
SAQID INTEGER NOT NULL, 
CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIME 



{ agent systusr.id 
{ sequence ) 
{ queue id 

{ create user id 
{ create date time 



{ id 
} 
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YEAR TO SECOND NOT NULL« 
CRTSRVR CHAR (15) NOT NULL. 
CRTCLNT CHAR (15) NOT NULL. 
CHGUSRID CHAR (15) NOT NULL. 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL. 
CHGSRVR CHAR (15) NOT NULL. 
CHGCLNT CHAR (15) NOT NULL. 



{ create server 

( create client 

{ change by user 

( change date time 

( change server 

{ change client 



PRIMARY KEY (ID) CONSTRAINT N30CSAASGNPK. 
UNIQUE (AGNUSRID. SEQ) CONSTRAINT N30CSAASGN1. 

FOREIGN KEY (AGNUSRID) REFERENCES SYSTUSR{ID) CONSTRAINT N3 OCSAASGNFKl. 
FOREIGN KEY(SAQID) REFERENCES N30TSAQ(ID) CONSTRAINT N30CSAASGNPK2 
) LOCK MODE ROW; 

INSERT INTO SYSTID (NM, LSTID) VALUES { "N30TSAASGN" , 1000); 

VIEW: Card Holder Apps Waiting TO be Processed 
Notes: Either IN SalcsWaittng status OR Suspended 
but suspense-until has expired. 

CREATE VIEW N30VAPPCH1 
AS 

SELECT * 

FROM N30TAPPCH 

WHERE CDAST = 6 

OR (CDAST=8 AND SUSDTTM IS NOT NULL AND SUSDTTM < (CURRENT YEAR TO SECOND) ) ; 

VIEW: Merchant Apps Wailing 

CREATE VIEW N30VAPPM1 
AS 

SELECT * 
FROM N30TAFPM 
WHERE CDAST » 6 

OR (CDASTsS AND SUSDTTM IS NOT NULL AND SUSDTTM < < CURRENT YEAR TO SECOND) ) ; 

MODIFY constraints ON cards TO allow multiple OF 
same card NUMBER AS LONG AS FOR diflerent dates 

ALTER TABLE N30TACCCHC DROP CONSTRAINT N30CACCCKC3; 

ALTER TABLE N30TACCCHC ADD CONSTRAINT UNIQUE (CNUM. BDT) CONSTRAINT N30CACCCHC3; 



ADD NEW card status FOR lost/stolen 
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INSERT INTO N30TCDCHCS (ID, DESC, AUTH) VALUES (30. 'Lost/Stolen', 'N'); 

VIEW: Merchant Apps Dups 

CREATE VIEW N30VAPPM2 (ID) 
AS 

SELECT MAX (ID) 
FROM N30TAPPM 
WHERE CDAST = 1 
GROUP BY CPNAM; 

VIEW: Card Holder Apps Dups 

CREATE VIEW N30VAPPCH2 (10) 
AS 

SELECT MAX (ID) 
PROM N30TAPPCH 
WHERE CDAST = 1 
GROUP BY CPNAM; 

VIEW: East Time Zone iMerchant Apps 

CREATE VIEW N30VAPPM3 
AS 

SELECT * 
FROM N30TAPPM 
WHERE CDAST = 6 

AND ST 
( 'ME' , 'NH' , 'VT' , 'NY' , 'PA' , 'WV' , 'VA' . 'OH' . 'MI' , ' IN' , 'NC , 'SC , 'GA' , 'FL' , 'NJ' , 'MA' , 'CT' , ' 
' RI • , • MD ' , • PR • , ' ON • , • QB ' , ' NB • , • NS ' ) ; 

VIEW: Central Time Zone Merchant Apps 

CREATE VIEW N3 0VAPPM4 
AS 

SELECT • 
FROM N30TAPPM 
WHERE CDAST » 6 

AND ST 
CND' , 'SD', 'MN», 'WI', 'lA' , 'NE- , 'IL', 'MS', 'KS' , 'OK' , 'KY', 'TN' . *AL', 'MS', 'LA' , 'TX', 'AR') ; 

VIEW: Mountain Time Zone Merchant Apps 

CREATE VIEW N30VAPPM5 
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AS 

SELECT ♦ 
FROM N30TAPPM 
WHERE CDAST = 6 

AND ST IN ( 'MT' . • ID' , 'WY* . •UT' , 'CO' . 'AZ' , 'NM* ) ; 

VIEW: Pacific Time Zone Merchant Apps 

CREATE VIEW N30VAPPM6 
AS 

SELECT * 
FROM N30TAPPM 
WHERE CDAST = 6 

AND ST IN ( 'BC , 'WA' , 'OR' , 'CA' . 'NV' . 'HI' , 'AKM ; 

VIEW: East Time Zone Card Holder Apps 

CREATE VIEW N30VAPPCH3 
AS 

SELECT * 

FROM N30TAPPCH 

WHERE CDAST s 6 

AND ST 
( 'ME' , 'NH', 'VT', 'NY' , 'PA' , 'WV' . 'VA* , ' OH' , 'MI ' , ' IN ' , 'NC , • SC , ' GA' , ' PL' , 'NJ' , 'MA' . ' CT' , • 
'RI' , 'MD' . *PR' , 'ON' , 'QB' , 'NB' , 'NS' ) ; 

VIEW: Central Time Zone Card Holder Apps 

CREATE VIEW N30VAPPCH4 
AS 

SELECT * 

FROM N30TAPPCH 

WHERE CDAST = 6 

AND ST 
( 'ND' , 'SD' , 'MN' , 'WI' , 'lA' , 'NE' , 'IL' , 'MS' , 'KS' . 'OK* , • KY' , 'TN' , ' AL ' , 'MS ' , 'LA' , 'TX' , * AR' ) ; 

VIEW: Mountain Time Zone Cardholder Apps 

CREATE VIEW N30VAPPCHS 
AS 

SELECT * 

FROM N30TAPPCH 

WHERE CDAST a 6 
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AND ST IN { 'MT' . *ID' . 'Wy» , 'OT' , 'CO' . 'AZ' , 'NM' > ; 

VIEW: Paciflc Time Zone Card Holder Apps 

CREATE VIEW N30VAPPCH6 
AS 

SELECT * 

FROM N30TAPPCH 

WHERE CDAST s 6 

AND ST IN ( 'BC , 'WA' , 'OR' , 'CA' . W , 'HI* , 'AK' ) ; 

Table 53: N30TBDCXREF 

CREATE TABLE N30TBDGXREF 
( 

ID INTEGER NOT NULL , 

ACCCHCID INTEGER NOT NULL , 

BDGID CHAR (50) NOT NULL , 

CRTUSRID CHAR (15) NOT NULL , 

CRTDTTM DATBTIME YEAR TO SECOND NOT NULL « 

CRTSRVR CHAR (IS) NOT NULL , 

CRTCLNT CHAR < 15) NOT NULL , 

CHGUSRID CHAR (15) NOT NULL , 

CHGDTTM DATETINE YEAR TO SECOND NOT NULL , 

CHGSRVR CHAR (15) NOT NULL . 

CHGCLNT CHAR (15) NOT NULL , 

UNIQUE (BDGID) CONSTRAINT " INFORMIX" .N30CBDGXREF1, 
PRIMARY KEY (ID) CONSTRAINT " INFORMIX" .N30CBDGXREFPK 
) LOCK MODE ROW; 
ALTER TABLE N30TBDGXREF ADD ACCID INTEGER NOT NULL; 

ALTER TABLE N30TBDGXREF ADD EXPDT DATE; 
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WHAT IS CLAIMED IS : 

1 . A method of conducting electronic commerce, the method comprising: 
receiving an electronic authorization request from a vendor for a payment 

guarantee, wherein the authorization request identifies a transaction amount between the 
5 vendor and a buyer; and 

electronically transmitting to the vendor a guarantee of payment for the transaction 
amount, wherein the guarantee is conditional to the occurrence of one or more events. 

2. The method of Claim 1, wherein one of the events is receipt of an invoice from the 

vendor. 

10 3. The method of Claim 1, comprising charging the vendor a transaction fee 

regardless of the occurrence of the conditions. 

4. The method of Claim 3, wherein the transaction fee is based at least in part upon 
either the transaction fee or a payment due date. 

5. The method of Claim 1, additionally comprising: 

IS receiving an invoice from the seller, wherein the invoice identifies an actual 

transaction amount of a transaction between the buyer and the seller; and 
storing the actual transaction amount in a database. 

6. The method of Claim 1, additionally comprising transmitting the invoice to a 
guarantor. 

20 7. The method of Claim 1, additionally comprising determining whether to guarantee 

payment. 

8. The method of Claim 1, wherein determining whether to guarantee payment is 
based at least in part upon a credit limit of the buyer. 

9. The method of Claim 1 , additionally comprising: 

25 receiving an invoice from the seller, wherein the invoice identifies a payment due 

date; and 

determining, based at least in part upon the due date, a fee that is due by the seller. 

10. The method of Claim 9, additionally comprising: 
receiving payment from the buyer; and 

30 sending payment to the vendor subsequent to subtracting the determined fee. 

11. The method of Claim 1, wherein the guaranteeing payment comprises insuring 
payment by the seller. 

12. The method of Claim 1, wherein guaranteeing payment comprises purchasing a 
receivable from the vendor. 

35 
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13. A system for conducting electronic commerce, the system comprising: 

means for receiving an electronic authorization request from a vendor for a 
payment guarantee, wherein the authorization request identifies a transaction amount 
between the vendor and a buyer; and 
5 means for electronically transmitting to the vendor a guarantee of payment for the 

transaction amount, wherein the guarantee is conditional to the occurrence of one or more 
events. 

14. The system of Claim 13, wherein one of the events is receipt of an invoice from 
the vendor. 

10 IS. The system of Claim 13, comprising means for charging the vendor a transaction 

fee regardless of the occurrence of the conditions. 

16. The system of Claim 15, wherein the transaction fee is based at least in part upon 
either the transaction fee or a payment due date. 

1 7. The system of Claim 1 3, additionally comprising: 

15 means for receiving an invoice from the seller, wherein the invoice identifies an 

actual transaction amount of a transaction between the buyer and the seller; and 
means for storing the actual transaction amount in a database. 

18. The system of Claim 13, additionally comprising means for transmitting the 
invoice to a guarantor. 

20 19. The system of Claim 13, additionally comprising means for determining whether 

to guarantee payment. 

20. The method of Claim 13, wherein the means for determining whether to guarantee 
payment reads a credit limit of the buyer from a database. 

2 1 . The system of Claim 1 3, additionally comprising: 

25 means for receiving an invoice from the seller, wherein the invoice identifies a 

payment due date; and 

means for determining, based at least in part upon the due date, a fee that is due by 
the seller. 

22. The system of Claim 2 1 , additionally comprising: 
30 means for receiving payment from the buyer; and 

means for sending payment to the vendor subsequent to subtracting the determined 

fee. 

23. The system of Claim 13, wherein the means for guaranteeing payment issues an 
insurance policy on the transaction. 
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24. The system of Claim 13, wherein the means for guaranteeing payment purchases a 
receivable from the vendor. 
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1 . Bank A issues line of credit to buyer and guarantees receivables. 

2. Bank B issues line of credit to seller and guarantees receivables. 

3. Buyer makes purchase from Seller available credit is checked and approved/denied. 

4. Buyer makes payment into lockbox of Bank B 

5. Bank B makes payment to Seller's Merchant bank 

6. Bank B updates Authorhative Database of payment and available credit limit is adjusted. 
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Approval Screen 



mm 



^ 

Back Forward R«1o«d 



Home Search Guide Images 



Print Securiiy Stop 




Netsite: 




GUARANTEE YOUR 
RECEIVABLES 



ENTER YOUR USER to 



lib 



*********** 



TER PASSWORD 



((enter)) 



WHOLESAl^-WEB; 

ilj^^lSTbRE^S^' 



YOUR COMPANY INTERNATIONAL 

2544B Costanza Blvd. Suite 800 
Chicago, IL 65330 



Enter Card Number, Expiration date and Amount below then 'VERIFY" 
NoOO Card Number Expiration Dato Amount Purchase Order (optional) 

I 6526>7 166-91701 106/2003 I I $ 4300.00 i \ PO 8996492 



Company 



PH1U.YBUSTER DESIGNS 
iiSf Darth 0iWe ; ' 
WallawaltaVtfA 38115 

JACKSON -HILL 
9534 Blister Ave. 
Wailawalla Wl 55143 

GRAVITOSt SYSTEMS 
4441 Beanieprop Blvd.. 
Wa!lawi;IIa AL 57682/ 

SUZIE'S BOUTIQUE 
581 3 Mall Ridge 
Wailawalla AZ 38115 



Card Number 



PS'6626^7i66.9170 

fatp:06>2603>" 

PS 9926-5846-3496 
exp. 08/2002 

PS 9354-3352-1774 
exp. 12(200.3 

PS 6526-7166-9170 
exp. 06/2003 



' ((VERIFY)) 



8996492 



Amount 



$ 4i^^:qo ' 

5 6 J66.00 

$12,800:00 44131 



$ 600.00 



When finished click on '^P I ease Approve** for Approval Codes 
on the selected orders above 



131 

C PLEASE 
APPROVE Jj 



To edit records enter 
Company Name [] 



or Approval Code PS74355 



I ((search)) 



(# rh«i)5//lg5M45/l6';6r.^b/rtar1<eVi^^ 
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Approval Screen 



Back Forward Reload 



^ ^ Bl ^ 
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19 



Netsite: ^[ 




GUARANTEE YOUR 
RECEIVABLES 



ENTER YOUR USER ID 



enter)) 



S\.:::;^ST6RjESsa&^ 



WHpLESAtE.WEB 



ALPliUVBETjlCALtV 



YOUR COMPANY INTERNATIONAL 

25446 Costanza Blvd. Suite 800 
Chicago, IL 65330 



Results for your request have been processed. 



Company 



PHILLYBUSTER DESIGNS^ 

JACKSON-HILL 
9S34 BUsterAve. 
WalfawalJaWt 65143 

4441 Beariieprop Bl^d^^ 
WaUawalliiAL 57662 

SUZIE*S BOUTIQU£ 
5813 Mall Ridge 
WallawallaAZ 38115 



Amount 


Approval Code 


$.4,300:60 -r *' • 


ApRrbved - PS74iss^ 


$ 6,766.00 


Approved • PS642a8 


$i2^ba6a; 


pjENlEb ^Over credtt.ll^ 


S 500.00 


Approved - PS11298 



I PONE j ) 
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Edit Screen 



"^^^ 

Back Forward R<»load 



Home Search Guide 



il ^ 

Images Print Securiiy Stop 




Netsite: 
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j »»»^l» <ll<H i* j 



ENTER PASSWORD 



(( ENTER)) 



5>i^ RETAILWEB 

^>-'vSTQRES7;?i-v,=. 



WHOLESALEWEB 

/•:l;-;:.-^sTbREs^;;;^;; 



ALPHABCTWU-Y; 



YOUR COMPANY INTERNATIONAL 

25443 Costanza Blvd. Suite 800 
Chicago, IL 65330 



EDIT TRANSACTION RECORD 



Company 



Card Number 



Amount 



PHILLYBUSTER DESfGNS [PS 6S26>7t 66^91 70 1 | $ 2.500.00 j | 6996492 | 

1 67 Darth Drive i 1 *— — ' 

Wallawalla WA 3811 5 I ex p. 06/2003 j 



When fTnishWd cllck;,^ for ^ 



RECALCULATE 
APPROVAL 
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Financial 
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Customer 
assigned 
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CTedit limit & ID 
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updated 



1 . Existing Customer or New User visits Prof itScape web site 

2a. New User Applies for membership and line of credit with guaranteed receivables 

2b. Existing Customer logs in with user name and password 

2c. Existing Customer or New User goes to ProfitScape Platform Web sites 

3. Application for credit and guarantees forwarded to linancial institution for review. 

4a. Application for credit denied-Customer notified 

4b. Application for credit approved-Customer assigned guaranteed credit limit and ID 
and entered into database 
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This \s the screen the buyer will view to identify due dates, 
authorizations, invoices, and amounts and make payments. 









BUYER STATEMENT 










BUYER NAME: AA TILE CO LTD 


GMAC # 904700 












AVAILABLE CREDIT: $xx.xxx.xx 
















nijp WiTMiN 
L/uc vYi 1 nin 




















Q*oD uays 








References 










DUE 


MERCHANT 


AUTH 


Al ITM 


PO 


PO 


INV 


INV 






Date 


Name 


# 


Date 


# 


Date 


# 


Date 


AMOUNT 


5/1/00 


Tommy Tunes 


1032 


4/1/00 


103200 


4/1/00 


103200 


4/1/00 


$ 


250.00 


5/4/00 


Hart Throb 


1133 


4/4/01 


113311 


4/4/01 


113311 


4/4/01 


$ 


592.78 
















TOTAL 


$ 


842.78 


PAST DUE 




















1-30 Days 




















4/11/00 


Dusty Clothes 


570 


3/11/00 


93200 


3/11/00 


93200 


3/11/00 


$ 


250.00 


4/14/00 


Lawn Rugs 


680 


3/14/00 


93311 


3/14/01 


93311 


3/14/01 


$ 


592.78 














Late Fee 


1.50% 


$ 


12.64 
















TOTAL 


$ 


855.42 


PAST DUE 




















1-30 Days 




















3/5/00 


Grave Stones 


125 


2/5/00 


3200 


2/5/00 


3200 


2/5/00 


$ 


500.00 


3/7/00 


Pet Jim 


153 


2/7/00 


3311 


2/14/01 


3311 


2/14/01 


$ 


1.592.78 














Late Fee 


2.50% 


$ 


31.39 
















TOTAL 


i 2.124.17 














GRAND TOTAL 


$ 3.822.37 




I 


Make Payments | 















flo HI 



PATENT COOPERATION TREATY 

PCT 



DECURATION OF NON-ESTABLISHMENT OF INTERNATIONAL SEARCH REPORT 
(PCT Article 1 7(2)(a), Rules 1 3ter.1 (c) and Rule 39) 



Applicant's or agent's file reference 
PSCAPE.004VP 



IMPORTANT DECLARATION 



Date of ma\\\ng(day/month/year) 

11/06/2001 



International application No. 

PCT/ US 01/04515 



international filing 6^{e(day/month/year} 

12/02/2001 



(Earliest) Priority datefday/mont/i/year^ 

11/02/2000 



Intenfiattonal Patent Classification (IPC) or both national classification and IPC 



G06F17/60 



Applicant 

PROFITSCAPE,COM, INC. et al , 



This InternationaJ Searching Authority hereby declares, according to Article 17(2)(a). that no international search report will 
be established on the international application for the reasons indicated below 

1 . [X] The subject matter of the international application relates to: 

a. I [ scientific theories. 

b. Q mathematical theories 

c. I I plant varieties. 

d. I I animal varieties. 

e. FT essentially biological processes for the production of plants and animals, other than microbiological processes 

and the products of such processes. 

f. ^schemes, njles or methods of doing business. 

g. schemes, rules or methods of performing purely mental acts. 

h. Q schemes, rules or methods of playing games. 

i. Q methods for treatment of the human body by surgery or therapy, 
j. Qjj methods for treatment of the animal body by surgery or therapy, 
k. \^ diagnostic methods practised on the human or animal body. 

I. Q mere presentations of information. 

m. 1^ computer programs for which this International Searching Authority is not equipped to search prior art. 



2-a 



3-D 



The failure of the following parts of the international application to comply with prescribed requirements prevents a 
meaningful search from b>etng carried out: 



I I the description 



I I the claims 



I I the drawings 



The failure of the nucleotide and/or amino acid sequence listing to comply with the standard provided for in Annex C of the 
Administrative Instnjctions prevents a meaningful search from being carried out: 



I I the written form has not been furnished or does not comply with the standard. 
I I the computer readable form has not been furnished or does not comply with the standard. 
4. Further comments: 



Name and mailing address of the International Searching Authority 
European Patent Office, P.B. 5818 Patentlaan 2 
MM NL-2280 HV Rijswijk 
w7/ Tel. (+31 -70) 340-2040. Tx. 31 651 epo nl, 
Fax: (+31-70) 340-3016 



Authorized officer 

Mar 'a Rodr'guez Novoa 



Form PCT/ISA/203 (July 1998) 



tnternational Application No. PCT/US Q1/Q4515 



FURTHER INFORMATION CONTINUED FROM PCT/ISA/ 203 



The subject-matter claimed in claims 1-12 falls under the provisions of 
Article 17(2)(a)(i) and Rule 39.1(iii), PCT, such subject-matter relating 
to a method of doing business. 

Claims 13-24 relate to a conventional system (program product, computer 
readable medium) for performing the business method of claims 1-12. 
Although these claims do not literally belong to the method category, 
they essentially claim protection for the same conmercial effect as the 
method claims. The International Searching Authority considers that 
searching this subject-matter would serve no useful purpose. It is not at 
present apparent how the subject-matter of the present claims may be 
considered defensible in any subsequent examination phase in front of the 
EPO as International Preliminary Examining Authority with regard to the 
provisions of Article 33(1) PCT (novelty, inventive step); see also 
Guidelines B-VII, 1-6). 

The applicant's attention is drawn to the fact that claims relating to 
inventions in respect of which no international search report has been 
established need not be the subject of an international preliminary 
examination (Rule 66.1(e) PCT). The applicant is advised that the EPO 
policy when acting as an International Preliminary Examining Authority is 
normally not to carry out a preliminary examination on matter which has 
not been searched. This is the case irrespective of whether or not the 
claims are amended following receipt of the search report or during any 
Chapter II procedure. If the application proceeds into the regional phase 
before the EPO, the applicant is reminded that a search may be carried 
out during examination before the EPO (see EPO Guideline C-VI, 8.5), 
should the problems which led to the Article 17(2) declaration be 
overcome. 



(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



CORRECTED VERSION 



(19) World Intellectual Property Organization 

International Bureau 

(43) International Publication Date 
16 August 2001 (16.08.2001) 




(10) International Publication Number 

PCT WO 01/058242 A2 



(51) International Patent Classification^: G06F 17/00 

(21) International Application Number: PCT/USO 1/045 15 

(22) International Filing Date: 12 February 2001 (12.02.2001) 

(25) Filing Language: English 

(26) Publication Language: English 

(30) Priority Data: 

60/182.017 1 1 February 2000 (1 1.02.2000) US 

60/206,847 23 May 2000 (23.05.2000) US 

^= (71) Applicant (for all designated Stales except US): PROF- 
= ITSCAPE.COM, INC. [US/US]; 6225 South Industrial 
Road, Las Vegas, NV 89118 (US). 

^= (72) Inventors; and 

== (75) Inventors/Applicants (for US only): TREIDER, Kevin, 
■gag C. [US/US]; 7418 Abbeyville Lane, Las Vegas, NV 891 19 
= (US). BORCES, Julie, M. [USAJS]; 1339 Finale Une, 
^= Las Vegas, NV 891 19 (US). 

^= (74) Agent: HUNT, Dale, C; Knobbe, Martens, Olson & 
Bear, LLP, 16th Floor, 620 Newport Center Drive, New- 
aa port Beach, CA 92660 (US). 

^= (81) Designated States (national): AE, AG, AL, AM, AT, AT 
aaaa (utility model), AU, AZ, BA, BB, BG, BR, BY, BZ, CA, 



CH, CN, CR, CU, CZ, CZ (utility model), DE, DE (utility 
model), DK, DK (utility model), DM, DZ, EE, EE (utility 
model), ES, H, FI (utility model), GB, GD, GE, GH, GM, 
HR, HU, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK, 
LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, 
MZ, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK. SK 
(utility model), SL, TJ. TM. TR, TT, 1Z, UA, UG, US, UZ, 
VN, YU, ZA, ZW. 

(84) Designated States (regional): ARIPO patent (GH, GM, 
KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian 
patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European 
patent (AT, BE, CH, CY, DE, DK, ES, FI. FR, GB, GR, IE, 
IT, LU, MC, NL, PT, SE, TR), OAPI patent (BF, BJ, CF, 
CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG). 

Published: 

— with declaration under Article 1 7(2)(a); without abstract; 
title not checked by the International Searching Authority 

(48) Date of publication of this corrected version: 

17 October 2002 

(15) Information about Correction: 

see PCT Gazette No. 42/2002 of 17 October 2002, Sec- 
tion H 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations" appearing at the begin- 
f^ing of each regular issue of the PCT Gazette. 



< 
n 

00 
IT) 



Q (54) Title: ELECTRONIC FACTORING 
^ (57) Abstract: 



wo 01/058242 



PCTAJSOl/04515 



ELECTRONIC FACTORING 
Background of the Invention 

Field of the Invention 
5 The invention relates to the field of electronic commerce. 

DescriptioD of the Related Art 

Factoring includes buying and selling accounts receivable and credit insuring. Accounts 
receivable are purchased based upon the assumption that the accounts receivable are valid and 
collectable. Accounts receivable are sold in order to quickly obtain cash for cash flow purposes, 

10 rather than to retain them as receivable. Accounts receivable are also frequently used as an asset 
upon which to borrow money^ in order to finance other unrelated transactions. Credit insuring 
occurs when an entity insures payment of an account receivable for a vendor, so that if the buyer 
does not pay, the insurer will. With the recent rapid growdi of information applications on the 
Internet, computer networks have the potential to establish a new kind of open market place for 

IS goods and services. Buyers and sellers increasingly want to use tlie Internet to conduct their 
business electronically. This new method of doing business is referred to as electronic commerce, 
or "e-commerce." 

The timely and costly process of processing paper requests for transactions such as the 
buying and selling of accounts receivable, as well as goods and services, plagues business 

20 transactions. Furthermore, buyers and sellers must expend significant resources to make 
appropriate credit decisions regarding a transaction. In procurement transactions, it is customary 
for the transaction to involve some form of credit, such as "open account trade credit," provided by 
the seller generally at no charge to the buyer but for a set period of time, normally thirty days. 
Buyers generally do not explicitly pay for the receipt of open account trade credit, and consider 

25 this free credit part of the established buyer/seller relationship. Credit cards are also available for 
relatively small purchases and operate by having a financial institution issue the credit card, and a 
vendor bank provide the cardholder with a revolving line of credit that can be used to buy goods 
from sellers who accept the credit card. This allows tlie cardholder to pay for credit card purchases 
over a period of time at an interest rate set by the vendor bank. 

30 Other types of credit devices are travel and entertainment cards, which unlike credit cards, 

are considered to be open-ended credit with payment in full due at the time of billing, no extension 
of revolving credit to the buyer is provided by use of these cards, or cardholder. Credit, travel and 
entertainment cards provide a uniform level of risk assessment to the seller and the seller pays a 
pre-determined interchange fee regardless of the actual credit risk presented by the buyer. 
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Commercial transaction are evolving to include electronic communication of financial 
transactions. Advances in computer networks and communication systems now apply to 
processing purchase and credit transactions. An important application of liew computer 
technology is electronic commerce, which includes using electronic networks as a marketplace for 
S business and consumer transactions. Electronic commerce services can include electronic 
brokerages, distributorships or clearinghouses that facilitate trade with electronic interchange 
media, such as public networks, for example the Internet, or proprietary access networks. 

Electronic commerce, however, does not currently ofPer financial services to sellers, such 
as payment and credit assessments of buyers, electronic factoring and credit insuring of 

10 transactions. This need is usually fulfilled by relying on traditional techniques of credit analysis 
and payment before a transaction can be completed. 

Various patents discuss methods of performing e-commerce wherein buyers and sellers are 
connected, but none address the issue of electronic factoring and credit insurance. U.S. Patent No. 
4,992,940 to Dworkin, entitled "System and Method for Automated Selection of Equipment for 

15 Purchase Through Input of User Desired Specifications," discloses an automated system that 
assists the user in locating and purchasing goods and services sold by a variety of vendors. U.S. 
Patent No. 5,732,400, to Mandler, et al., entitled "System and Method for a Risk-Based Purchase 
of Goods," discloses a financial clearinghouse for receiving requests for goods or services from a 
buyer and making a real-time determination of a risk classification of the buyer using an online 

20 repository of credit information. U.S. Patent No. 5,757,917, to Rose, et al., entitled "Computerized 
Payment System for Purchasing Goods and Services on the Internet," discloses a computerized 
payment system that prequalifies and pays a buyer's order through a third party, but is not a 
guarantee-of-payment mechanism. U.S. Patent No. 5,822,737, to Ogram, entitled "Fmancial 
Transaction System," discloses an automated payment system allowing a consumer to purchase 

25 goods or services over the Internet with a credit card that is verified before making the payment. 
U.S. Patent No. 5,802,497, to Manasse, entitled "Method and Apparatus for Conducting 
Computerized Commerce," discloses the use of a broker, broker scrip, vendor scrip, and currency 
to sell parts and services and deliver to the consumer. U.S. Patent No. 5,745,886 to Rosen, entitled 
"Trusted Agents for Open Distribution of Electronic Money," discloses using a customer trusted 

30 agent and vendor trusted agent and establishing a crypto-graphically secure session, and to provide 
electronic money purchase or sale information and an account credential to the vendor trusted 
agent. U.S. Patent No. 5,557,518, also to Rosen, entitled "Trusted Agents for Open Electronic 
Commerce," also discloses the use of trusted agents, establishing a crypto-graphically secure 
session and electronically transferring funds in purchasing merchandise, U.S. Patent No. 

35 5,717,923, to Dedrick, entitled "Method and Apparatus for Dynamically Customizing Electronic 
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Information to Individual End Users," discloses maintaining a personal profile database to store 
consumer information and a consent adapter to compare electronic information received by a client 
system to consumer information in the personal profile database. 

U.S. Patent No. 5,717,989, to Tozzoli, et al., entitled "Full Service Trade System," 
5 discloses storing criteria specified by a funder relative to trade transactions for buyers and sellers 
and comparing the criteria with a proposed purchase order m order to determine whether the 
system can generate a payment guarantee on behalf of the funder for the buyer to the seller. U.S. 
Patent No. 5,826,241 to Stein, et al., entitled "Computerized System for Making Payments and 
Authenticating Transactions Over the Internet," discloses a payment system that provides 

10 cardholder accounts for first and second Internet users and making queries to the first user on 
whether to proceed vwth payment to the second user. U.S. Patent No. 5,842,178, to Giovannoli, 
entitled "Computerized Quotation System and Method,*' discloses a computer-based 
communications network of members for processing requests for quotes for goods and services, as 
well as storage containing the identification of the members and means for transmitting and 

15 broadcasting requests for quotes. U.S. Patent No. 5,694,551, to Doyle et al., entitled "Computer 
Integration Network for Channeling Customer Orders Through a Centralized Computer to Various 
Suppliers," discloses an electronic requisitioning system that channels customer orders to internal 
suppliers and outside vendors, and processes invoices. U.S. Patent No. 5,671,280, to Rosen, 
entitled "System and Method for Commercial Payments Using Trusted Agents," discloses a system 

20 for electronic payment using a customer trusted agent and a vendor trusted agent. U.S. Patent No. 
5,664,115, to Fraser, entitle d"Interactive Computer System to Match Buyers and Sellers of Real 
Estate, Businesses and Other Property Using the Internet," discloses automatically connecting 
sellers of property with potential buyers, preferably over the Internet, wherein the host system 
stores records regarding the properties and can be searched by potential buyers, and the system 

25 permits evaluation of potential buyers to screen them. 

Various articles have been written which disclose forms of electronic payment methods, 
but these methodologies only relate to moving money around, from one account to another, 
electronically and do not address the need in the marketplace for electronic factoring. 

Summarv of the Invention 

30 The invention comprises a method and system for electronic factoring. The inventive 

system overcomes all of the limitations of the prior art and addresses the need for an electronic 
commerce version for factoring. The system enables buyers to purchase goods from vendors with 
a third party guarantee to the vendor via electronic factoring that guarantees the payment. By 
using the system, electronic factoring, including credit insurance, is performed in an efficient 
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manner. The invention enables buyers to obtain goods and services immediately without having 
to pay for them at the time of the transaction. 

The invention also comprises a credit database set up for all users that assigns a credit 
limit to the customers for credit as well as a credit instrument for guarantee of pajmient to vendors. 
5 Payment is guaranteed through a banking partner, the guaranteeing financial institution, who 
guarantees all receivables that are created through the sales on the platform (entitled "ProfitScape" 
in the Figures) to ensure payment and security of the transaction. The system tracks and maintains 
a database that details credit dollar amounts available and account activity for each user. The 
invention defines a credit-worthy marketplace that enables users, who become members, to 

10 purchase goods and services on credit based on their respective financial positions which have 
been evaluated by the guaranteemg financial mstitution. 

In one embodiment, the method comprises the steps of providing an electronic platform for 
guaranteeing payment of receivables; inputting information trom users into a profile database upon 
the electronic platform; assigning buyers a credit limit; and guaranteeing payment to vendors for 

15 users who purchase from the vendor. Additionally, the method comprises linking at least two 
users, the users being either buyers, vendors, international licensees, or financial institutions for 
guaranteeing payment via the platform. Guaranteeing payment to vendors preferably comprises 
aligning the platform with a guaranteeing financial institution. Aligning the platform with a 
guaranteeing financial institution preferably comprises aligning the platform with that institution in 

20 order to perform a factoring-type such as credit insuring, full-factoring, or lending. The electronic 
factoring method can further comprise the steps of producing a symbol to represent each user's 
profile and exchanging information between users via the symbol on the electronic platform. 
Guaranteeing payment to vendors can comprise electronically sending the vendor the user's 
symbol in order to show the vendor that payment is guaranteed by the platform. The method can 

25 further comprise the steps of electronically sending the user's symbol to the guaranteeing financial 
institution and sending a guarantee of compensation from the guaranteeing financial institution to 
the vendor. Guaranteeing payment to vendors can comprise the steps of issuing each user an 
identifying card showing membership on the platform; purchasing from the vendor with the 
identifying card; and accessing the user's credit availability via the platform with the identifying 

30 card. 

Providing an electronic platform preferably comprises providing an Internet web site 
having the platform for users to access, and optionally comprises the step of providing Internet 
web site links for users to access other users' web sites. The step of inputting information from 
users into a profile database preferably comprises the steps of inputting data such as name, address, 
35 contact information, primary industry, credit insured amount, payment histoiy, credit usage, target 
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marketplace, products offered, services offered, inventory, buying trend data, and Internet usage 
data. 

The electronic factoring method further can comprise the steps of verifying a user as a 
member of the platform and purchasing from the vendor. Purchasing from the vendor can 
5 comprise first searching the profile database with a search engine, from the vendor preferably 
comprises purchasing from the vendor with a line of credit within the credit limit established by 
the profile database. 

Guaranteeing payment to vendors can comprise the steps of reassigning the receivable to 
the guaranteeing financial institution; making payment to the platform; and forwarding payment 

10 from the platform to the vendor. Guaranteeing payment to vendors can alternatively comprise 
reassigning the receivable to the guaranteeing financial institution; making payment to the 
guaranteeing financial institution; and forwarding payment from the guaranteeing financial 
institution to the vendor. In yet another embodiment, guaranteeing payment to vendors comprises 
accessing the platfonn directly by the vendor for verification of credit availability and forwarding 

15 payment to the vendor upon accessing the guaranteeing fmancial institution directly by the vendor 
for verification of credit availability and forwarding payment to the vendor upon verification. In 
still another embodiment, guaranteeing payment to vendors comprises accessing the guaranteeing 
financial institution directly by the vendor for verification of credit availability and forwarding 
payment to the vendor upon verification. Still another embodiment of guaranteeing payment to 

20 vendors comprises accessing the platform for verification of credit availability; paying the 
guaranteeing financial institution for purchases; and forwardmg payment from the guaranteeing 
financial institution to the platform and vendor bank so that the vendor bank can credit the vendor. 

TTie electronic factoring method also can comprise the steps of maintaining user credit 
records on the platform and periodically reviewing credit records by the financial institution for 

25 buyer credit availability. Linking at least two users can comprise the steps of creating offers by the 
vendor; sending the offers to an offer database on the platform for storage; comparing the offer 
database with the user profiles in the profile database; creating a list of matching offers and user 
profiles; and offering users those offers tliat match the user's profile upon log-in. 

In one embodiment, the invention also comprises a method of electronic factoring 

30 comprising the steps of assigning buyers a credit limit upon a guaranteeing platform; verifying the 
buyer's identification as a member of the guaranteeing platform; verifying the buyer's credit 
amount when the buyer attempts to make a purchase; subtracting the purchase amount from the 
buyer's available credit limit upon making a verified purchase; notifying the vendor of the 
purchase order; reassigning the receivable to a guaranteeing financial institution via the 

35 guaranteeing platfonn; billing the buyer for the purchase order; and forwarding payment to the 
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vendor. Forwarding payment to the vendor optionally comprises forwarding payment to the 
vendor from either the buyer, the guaranteeing financial institution, or the guaranteeing platform. 

In one embodiment, the invention also comprises an electronic factoring system for 
guaranteeing payment.of receivables and comprises an electronic platform; a profile database upon 
5 the electronic platform for inputting information from users; means for assigning buyers a credit 
limit; and means for guaranteeing payment to vendors for users who purchase from the vendor. 
The electronic factoring system can additionally comprise means for linking at least two users 
wherein the users consist of buyers, vendors, international licensees, and financial institutions for 
guaranteeing payment via the platform. Means for guaranteeing payment to vendors may comprise 

10 means for aligning the platform with a guaranteeing financial institution, and wherein said means 
for aligning the platform with a guaranteemg financial institution comprises aligning with a 
guaranteeing financial institution so that that institution can perform factoring such as credit 
insuring, full-factoring, or lending. The electronic system can further comprise means for 
producing a symbol to represent each user's profile, and means for exchanging information 

15 between users via the symbol on the electronic platform. Means for guaranteeing payment to 
vendors can comprise means for electronically sending the vendor the user's symbol in order to 
show the vendor that payment is guaranteed by the platform. The system can comprise means for 
electronically sending the user's symbol to the guaranteeing financial institution and means for 
sending a guarantee of compensation from the guaranteeing financial institution to the vendor. 

20 Means for guaranteeing payment to vendors can alternatively comprise an identifying card issued 
to each user showing membership on the platform; means for purchasing from the vendor with the 
identifying card, and means for accessing the user's credit availability via the platform. with the 
identifying card. 

The electronic platform of the electronic factoring system may comprise an Internet web 
25 site haying the platform available for users to access. The Internet web site can further comprise 
links for users to access other users' web sites. The profile database of the electronic factoring 
system may comprise a profile database for inputting data from users. This data can consist of any 
of the following: name, address, contact information, primaiy industry, credit insured amount, 
payment history, credit usage, target marketplace, products offered, services offered, inventory, 
30 buying trend data, and Internet usage data. 

The electronic factoring system can further comprise means for verifying a user as a 
member of the platform and means for purchasing from the vendor. Means for purchasing from 
the vendor can comprise means for first searching the profile database with a search engine. 
Means for purchasing from the vendor preferably comprises means for purchasing from the vendor 
35 with a line of credit within the credit limit established by the profile database. 
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Means for guaranteeing payment to vendors can comprise means for reassigning the 
receivable to the guaranteeing financial institution; means for making payment to the platform; and 
means for forwarding payment from the platform to the vendor. Alternatively, means for 
guaranteeing payment to vendors comprises means for reassigning the receivable to the 
5 guaranteeing financial institution; means for making payment to the guaranteeing financial 
institution; and means for forwarding payment from the guaranteeing jSnancial institution to the 
vendor. In still another embodiment, means for guaranteeing payment to vendor comprises means 
for accessing the platform directly by the vendor for verification of credit availability and means 
for forwarding payment to the vendor upon verification. In still another embodiment, the means 

10 for guaranteeing payment to vendors comprises means for accessing the guaranteeing financial 
institution directly by the vendor for verification of credit availability and means for forwarding 
payment to the vendor upon verification. In yet another embodiment, the means for guaranteeing 
payment to vendors comprises means for accessing the platform for verification of credit 
availability; means for paying the guaranteeing financial institution for purchase; and means for 

IS forwarding payment from the guaranteeing financial institution to the platform and vendor bank so 
that the vendor bank can credit the vendor. 

The electronic factoring system can further comprise means for maintaining user credit 
records on the platform and means for periodically reviewing credit records by the financial 
institution for buyer credit availability. Means for linking at least two users can comprise means 

20 for creating offers by the vendor; means for sending the offers to an offer database on the platform 
for storage; means for comparing the offer database with the user profiles in the profile database; 
means for creating a list of matching offers and user profiles; and means for offering users those 
offers that match the user's profile.upon login. 

The invention also comprises an electronic factoring system for guaranteeing payment of 

25 receivables comprising means for assigning buyers a credit limit upon a guaranteeing platform; 
means for verifying the buyer's identification as a member of the guaranteeing platform; means for 
verifying the buyer's credit amount when the buyer attempts to make a purchase; means for 
subtracting the purchase amount from the buyer's available credit limit upon making a verified 
purchase; means for notifying the vendor of the purchase order; means for reassigning the 

30 receivable to a guaranteeing financial institution via the guaranteeing platform; means for billing 
the buyer for the purchase order; and means for forwarding payment to the vendor. Means for 
forwarding payment to the vendor can comprise means for forwarding payment to the vendor from 
either the buyer, the guaranteeing financial institution, or the guaranteeing platform. 



-7- 



wo 01/058242 PCT/USO 1/0451 5 

One aspect of the invention can provide unique profiled information that is delivered 
through an electronic system using software agents that enable credit and/or a guarantee of 
compensation to vendors for buyers. 

Another aspect of the invention can include a unique database profile which is created 
3 incorporating specific sales and product information detailing what each user has to sell, terms, 
company history, unique product information, and the category of transaction, be it either a retail 
or wholesale target market. 

Another aspect of the invention can provide unique profiled information and open access 
to both buyers and vendors to find information and make purchases guaranteed for payment. 
10 Yet another aspect of the invention can enable users to find unique information that 

matches their targeted request and enables them to purchase and consummate transactions 
electronically. 

Yet another aspect of the invention comprises amethod of conducting electronic 
commerce, the method comprising: receiving an electronic authorization request firom a vendor for 

IS a payment guarantee, wherein the authorization request identifies a transaction amount between the 
vendor and a buyer; and electronically transmitting to the vendor a guarantee of payment for the 
transaction amount, wherein the guarantee is conditional to the occurrence of one or more events. 
. One of the events may be the receipt of an invoice from the vendor. A transaction fee may be 
charged regardless of the occurrence of the conditions. The transaction fee can be based at least in 

20 part upon either the transaction fee or a payment due date. Hie method may also comprise: 
receiving an invoice from the seller, wherein the invoice identifies an actual transaction amount of 
a transaction between the buyer and the seller; storing the actual transaction amount in a database; 
and transmitting the invoice to a guarantor. The method may also comprise gauranteeing payment 
based at least in part upon a credit limit of the buyer. The method may also comprise receiving an 

25 invoice from the seller, wherein the invoice identifies a payment due date; and determining, based 
at least in part upon the due date, a fee that is due by the seller. The method may also comprise 
receiving payment from the buyer; and sending payment to the vendor subsequent to subtracting 
the determined fee. Gauranteeing payment may comprise insuring payment by the seller or 
purchasing a receivable from the vendor. 

30 Another aspect of the invention comprises a system for conducting electronic commerce, 

the system comprising: means for receiving an electronic authorization request from a vendor for a 
payment guarantee, wherein the authorization request identifies a transaction amount between the 
vendor and a buyer; and means for electronically transmitting to the vendor a guarantee of payment 
for the transaction amount, wherein the guarantee is conditional to the occurrence of one or more 

35 events. 
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Brief Description of the Drawings 
The accompanying drawings, which are incorporated into and form a part of the 
specification, illustrate several embodiments of the invention and, together with the description, 
serve to explain the principles of the invention. The drawings are only for the purpose of 
S illustrating a preferred embodiment of the invention and are not to be construed as limiting the 
invention. In the drawings: 

Fig. lA is a block diagram of a first embodiment of the invention showing the flow of 
purchase and fulfillment between buyer and vendor using the electronic commerce web site 
platform of the invention; 

10 Fig. IB is a block diagram of a second embodiment of the invention showing the flow of 

purchase and fulfillment between buyer and vendor using the electronic commerce web site 
platform; 

Fig. IC is a block diagram of a third embodiment of the invention showing the flow of 
purchase and fulfillment between buyer and vendor using the electronic commerce web site 
15 platform; Fig. 2 is a block diagram of another embodiment of the invention wherein the 
buyer makes payment directly to the guaranteeing institution; 

Fig. 3 is a block diagram of the post-shopping experience for a user of the invention; 
Fig. 4 is a block diagram of the functions that an existing customer or new user proceeds 
through when visiting the web site platform of the invention; 
20 Fig. 5 is a block diagram showing the functions that a user proceeds through with customer 

service; 

Fig. 6 is a block diagram showing a user searching the database of the invention and 
consummating a transaction with a link to other web sites; 

Figs. 7a-7e demonstrate the algorithmic methods of communication for the various 
25 embodiments of the invention; 

Fig. 8 is a flow diagram showing the first international licensee embodiment of the 
invention in the first page; 

Fig. 9 is a flow diagram showing the first international licensee embodiment of the 
invention in the second stage; 
30 Fig. 10 is a flow diagram of a second international licensee embodiment of the invention 

in the first stage wherein the financial institution of guarantee works directly with the international 
licensee; 

Fig. 1 1 is a flow diagram of a second international licensee embodiment of the invention 
in the second stage; 

35 Fig. 12 is a third international licensee embodiment of the invention; 
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Fig. 13 is a fourth international licensee embodiment of the invention; 
Fig. 14 is a flow chart showing the connection being made between user and vendor; 
Fig. 15 is a flow chart showing the user application for credit; 
Fig. 16 is a flow chart showing the user log-in to the invention; 
S Fig. 17 is a flow chart showing the user making a purchase through the methodology of the 

invention; 

Fig. 18 is a flow diagram of an alternative embodiment of the invention wherein both a 
guarantor bank and a vendor bank are used in the process; 

Fig. 19 is a flow diagram of another alternative embodiment of the invention wherein both 
1 0 a guarantor bank and vendor bank are used; 

Fig. 20 is a flow diagram of the preferred user login to a web site according to the 
invention; 

Fig. 21 is a flow diagram of the preferred purchase transaction according to the invention; 
Fig. 22 is a flow diagram of a first interaction with two guarantor banks; 
1 5 Fig. 23 is a flow diagram of a second interaction with two guarantor banks; 

Fig. 24 is a flow diagram of a preferred lockbox of the invention; 

Fig. 25 is an illustrative approval screen in a web page according to the invention prior to 
submission; 

Fig. 26 is an illustrative approval screen in a web page according to the invention after 
20 submission; 

Fig. 27 is an illustrative edit screen; 

Fig. 28 is a top-level flow diagram of the preferred web site of the invention in conjunction 
with customer web sites; 

Fig. 29 is an illustrative purchase screen; 
25 Fig. 30 is an illustrative invoice screen; 

Fig. 3 1 is an illustrative payment screen; 

Fig. 31 A is an illustrative first confirmation screen; 

Fig. 3 IB is an illustrative second confirmation screen; 

Fig. 32 is a flowchart illustrating vendor recruitment; 
30 Fig. 33 is a flowchart illustrating buyer recruitment; 

Fig. 34 is a flowchart illustrating an exemplary trade show purchase; 

Fig. 35 is a flowchart illustrating shipment of a trade show purchase; 

Fig. 36 is an exemplary network that may be used in conjunction with electronic platform 
of the invention; 
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Fig. 37 is yet another exemplary network that may be used in conjunction with the 
electronic platform of the invention; 

Figs. 38, 39, and 40 are each a diagram illustrating the contents of selected fields of the 
database during an exemplary transaction; and 
S Fig. 41 is a screen display showing an exemplary report that is presented that shows the 

transaction history for a user of the electronic platform of Figs. 1 A, IB, IC and 2, 

Detailed Description of the Invention 
In one embodiment, the invention comprises a payment or credit anangement process 
wherein payment of all transactions are guaranteed through a platform, and aligned guaranteeing 
10 financial institution (or guarantor bank). All users, whether buyers or sellers ("vendors") are put 
into a profile database that defines their credit amount, credit used, and credit available. A unique 
number is then assigned to each user that will be used as an identifying symbol to be held in the 
electronic database. This symbol, or digital representation thereof, represents a profile enabling 
users to obtain and utilize credit to facilitate purchases of goods, services, and other intangibles 
1 S through the system. The information and implementation of the invention is preferably distributed 
electronically over data lines into a worldwide web platform to facilitate users' purchase 
transactions or vendors' sales needs. 

The digitally produced symbol is delivered electronically via data lines to find targeted 
information, and enables the buyer to purchase goods, services, or other intangibles ordered 
20 through the system. A search engine is used to locate the required information over a network of 
profiled vendors. The same process operates in reverse to also link vendors to buyers. Information 
using software agents can be accessed electronically based on an Alchemy model that enables 
users to seek and match their specific requests. The unique symbol that is assigned for the 
vendor's profile, as well as a specific symbol representing the targeted audience of buyers, with 
25 additional symbols or digital representations for other information, allows for an efficient and 
easy-to-use exchange of information. Additionally, proprietary profiles can be maintained to 
facilitate electronic commerce for users within the database to exchange information and to target 
specific information to a targeted audience. 

Vendors benefit by reaching buyers through the system and offering credit to purchase 
30 their goods, services, or other intangibles. Competing advertising members can use the system to 
reach the attention of users who wish to seek information residing on the system as well. Vendors 
can use the credit system to sell to buyers within the profile database to ensure future payment of 
goods that are sold on a time-delay process unique to each of the profiled users. 

By electronically transmitting the symbol, the user can deliver a promise of compensation 
35 to be paid immediately, or in the future. By using software agents, the electronic database 
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transmits digital information electronically to those users who are seeking to receive compensation 
in exchange for releasing the items that the user/buyer has requested. The digitally produced 
symbol simultaneously instructs a third party to deliver a guarantee of compensation on behalf of 
each user. The third party guarantees compensation to the vendor in the form of either credit 
S insuring, full-factoring, or lending based upon accounts receivable. 

The platform streamlines the buying process and saves time by alleviating the need for 
C.O.D., prepayment with a Visa or MasterCard and excessive paperwork necessary for approval 
through multiple factoring banks. 

Often the vendor will need their money before they can ship the order: perhaps the money 
10 is needed to produce the order. In this case, called factoring, the vendor pays a higher fee to 
ProfitScape in order to obtain their money early. The vendor sells the receivable to the factor: 
once payment is made, the payment will be sent to the factor. This is done with or without the 
knowledge of the cardholder. 
Actors 

15 The following table documents some of the roles played by users of the system and a 

summary of how users interact with the system. A role or actor refers to one, possibly of many, 
motivations driving a user to interact with the system. The same user may have different roles at 
different times. 

20 



ACTOR 


INTENT 


Vendor 


The vendor, also known as the vendor, is selling 
product to the buyer and accepting payment via 
the system. The term Vendor is used as it is with 
consumer credit. 


Vendor/S^les 


1. Originate requests to guarantee payment, 
using trade show device or WUI, possibly even 
telephone. 

2. Check status of PENDING authorizations to 
determine whether to ship goods or not. 

3. View/print reports of outstanding System 
settlements. 


Vendor/Accounts Receivable 


1. View/print reports of outstanding/all/for a 
given cycle System settlements 

2. Track invoice number in system 

3. Receive statement of invoices being paid 
along with a check 


Vendor/Administrative User 


1 . View/ Edit Account 
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ACTOR 


INTENT 


Cardholder 


The cardholder, also known as the buyer, is 
buying goods and wishes to settle the purchase 
via the system. 


Cardholder/Buyer 


1. Use card to guarantee payment on orders, 
vendor can ship order without due diligence etc. 

2. View/print reports of transactions. 

3. Research invoice/PO discrepancies 


Cardholder/Accounts Payable 


1. View/print reports of outstanding/all/for a 
given cycle payables 

2. Remit payment for vendor invoice to card 
issuer. 


Cardholder/Administrative User 


1. View Accounts 


ProfitScape/New Cardholder Accounts 


1. Process pre-approve batches submitted by 

associations. 


ProfitScape/New Vendor Accounts 


1. Process vendor batches submitted by 
associations and web portals. 

2. Work with new vendors to ensure their full 
and proper use of service. 


ProfitScape/Customer Service 

IvCpi CoCIiLdllVv 


1. Respond to customer account inquiries 

2. Cancel authorizations. 

3. Manual card issue. 


ProfitScape/Risk & Quality Management 


1. View/print reports of late payers towards 
getting them to be on time 

2. Work with Guarantors' collection personnel. 


ProfitScape/GL Accounting 


1. View/print reports of transaction 
summary/detail to balance GL accounts 

2. Post journal entries to GL 


ProfitScape/System Accounts Payable 


1. Prepare and reconcile batch of vendor 
statements/checks. 

2. Print batch, z-fold into envelopes for mailing 

3. View/print reports of posted/unposted vendor 
checks 

4. Reconcile bank statement to unposted vendor 

checks. 


ProfitScape/System Accounts Receivable 


1. View/print reports of delinquent cardholders. 

2. Process received payments, one payment = 
multiple invoices. 
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ACTOR 


INTENT 


ProfitScape/Administrative User 


1. Configure system codes 




2. Create and maintain user profiles and security 




constraints. 


Guarantor/Administrative User 


1. View/Edit Accounts 


Guarantor/Collections 


1. View/Edit Accounts 


Factor/Administrative User 


1. View/Edit Accounts 



Use Cases 

A use-case is a single scenario depicting how users are interacting with the system to 
achieve a specific goal. 
5 Process Pre-Approved Batch 

This case depicts the card issuer receiving a large number of proposed cardholders from a 
third party. The card issuer eliminates duplicates, creates the cardholder accounts, and submits 
their information to a guarantor for credit line approval. 

In one embodiment, an association submits a file to the card issuer, who in turn attempts to 
10 submit the file to the system. The system verifies file contents (headers, counts, formats, etc). The 
entire file is either accepted or rejected. If accepted, the file creates a batch in the database for 
processing. The card issuer processes batch, creating cardholder accounts where needed and 
marking each batch entry with the account number. Existing accounts are left alone, since the 
original association receives the fee (if any) for sourcing those records. The system marks any 
15 created cardholder records with the association as the source. In some cases the association will 
receive a permanent fee percentage of all transactions. The system generates batches for 
guarantors for credit line approvals. The card issuer submits credit line request batches to one 
or more guarantors. In response, guarantors submit a credit line response batch to the card issuer. 
The card issuer processes credit line batch, updating customer records. The card issuer prints a 
20 processing report (to printer or file) for the association to track results. 

Cards are then ready to be issued or other responses are generated. For example, customer 
service representatives for the card issuer can contact the applicant to counsel them towards getting 
approval, possibly from a different guarantor. 
Process Vendor Batch 

25 Associations can submit large groups of vendor records. Also, Vendors may sign 

themselves up for the service. Web portals may submit vendor batches as well. An exemplary 
process is set forth below that describes a process for creating new vendor accounts. 

An association or some other verified source submits a file to the card issuer. A CSR 
representative for the card issuer verifies file contents and either accepts or rejects the entire file. 
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If accepted, a New Vendor Accounts batch is created, waiting to be processed. Next, the card 
issuer processes file, creating vendor accounts where needed, and marking each batch record with 
the account number and status. In one embodiment, existing accounts are left alone. Letters are 
then issued to vendor informing them of their account, status, and usage procedures. 
5 Create Cardholder 

The card issuer can create a single cardholder account at a time as well as the batch pre* 
approved process. 
Issuing Cards 

One or more cards are issued to specific people within a company. The credit line 
10 authorization of a company can be divided among one or multiple card users. Even with multiple 
cards, the total authorization will not exceed the total credit line of a company. 

A company can: (i) authorize the entire credit amount to one person on one card; (ii) 
divide the entire credit amount among multiple people, each having their own card; (iii) allow a 
"key signatory" to access to the entire credit amount on a card, plus divide the entire credit amount 
15 among multiple people, each having their own card, or (iv) authorize the entire credit amount to 
multiple people, each having their own cards. As discussed, cards may be issued in large batches, 
sent out for embossing, or one at a time like temporary cards at a trade show. Again, batches are 
created, edited, posted. 

The following table summarizes each of the foregoing situations: 

20 



Card Type 


Description/Example 


Single Card 


The company is authorized a single card with 
the entire credit limit assigned to that one card. 


Multiple Cards 1 


A single credit limit is authorized to a 
company and the authorizing company "key 
signatory" later autliorizes six users. Each user 
is then authorized, by the "key signatory", a 
specific amount of the credit limit, totaling up 
to; but, not more than the credit limit. The 
authorized amount may be equal or 
disproportional — depending on the "key 
signatories" perspective. (100% of the credit 
limit is divided between the key signatory and 
the six users). 
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Card Type 


Description/Example 


Multiple Cards 2 


A single credit limit is authorized to a 
company and the authorizing company "key 
signatory" later authorizes six users. In this 
scenario, the "key signatories" card is 
authorized for the total amount of the credit 
limit. Each of the other 6 authorized users are 
then authorized, by the "key signatory, a 
specific amount of tlie credit limit, totaling up 
to; but, not more than the credit limit The 
authorized amount may be equal or 
disproportional — depending on the "key 
signatories" perspective. Typically, the 
aggregate amount of any two or more card's 
use may not exceed the total credit limit. 
(100% of the credit limit is divided among the 
six users; and, the key signatory has access to 
the entire credit limit). 


Multiple Cards 3 


A single credit limit is authorized to a 
company and the authorizmg company "key 
signatory" later authorizes six users. In this 
scenario, any of the authorized card users, 
including the "key signatory", may spend the 
total amount of the credit limit; BUT, under no 
circumstances may the aggregate amount of 
any two or more card's exceed the total credit 
limit. (100% of the credit limit is equally 
available to all 7 users). 



In one embodiment of the invention, the card can be co-branded by a credit card provider. 
In this embodiment, at a point of purchase, the user can request to use the card as a credit card, or, 
S alternatively, as a card as is described for use with the embodiments of the invention shown in 
Figures 1-41. Furthermore, in this embodiment, the card is associated with at least two credit 
limits: the first credit limit identifying a credit limit with respect to the credit card provider and a 
second credit limit associated with the use of the card in conjunction with the system shown in 
Figures 1-41. Furthermore, in one embodiment of the invention, the card contains two sets of 
10 account information: a first set is associated with the credit card provider and a second set is 
associated with respect to the use of the card in conjunction with the system shown in 
Figures 1-41. 
Tradeshow 

In one embodiment of the invention, custom cards are issued as part of a tradeshow. In 
15 this embodiment, the cards have identifying information displayed on the card thereby serving as a 
badge. The card may be activated by providing the credit vendor a credit application and 
requesting the credit vendor to activate the card. Once activated, the credit vendor provides an 
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insignia to the buyer. The buyer places the insignia on or near the card via an adhesive. The 
insignia identifies to sellers that the buyer has at least a threshold level of credit. In another 
embodiment of tlie invention, upon approving the buyer's application for a card, the buyer is 
provided a card having a certain color that is different than the. individuals that have not been 
5 approved to receive credit. 
Create Vendor 

The card issuer can create a single vendor account at a time as well as part of the batch pre- 
approved process. 
Purchase Guarantee Payment 
10 The following describes a process of guaranteeing payment for a transaction. First, a 

cardholder places order, verbal, PO, with a vendor. 

The vendor submits authorization request to ProfitScape/system (card #, expiration name, 
name, amount, PO). The system verifies credit balance, issues authorization code, decline, 
pending, or other response message. Exemplary response codes may be found in the Visa 2 
IS Specification. 

If amount requested puts cardholder over the cardholder's credit limit, a PENDING 
response is issued and submitted to the guarantor. The guarantor can approval the transaction 
and/or or increase the cardholder's credit limit. The card issuer can generate reports of PENDING 
authorizations to ensure that they are being answered in a timely manner. The vendor ships goods, 

20 sends invoice to the card issuer with an authorization code. The vendor sends an invoice to the 
cardholder requesting the cardholder to remit payment to the guarantor, or alternatively, the card 
issuer. In one embodiment, the card issuer has online forms for vendors to submit invoices. 

In one embodiment, the vendor incurs a payment term guarantee fee at the time of 
approval of the transaction. Each vendor obtains an approval for a specific buyer (i.e., one 

25 cardholder). Each approval can cover multiple invoices for a specific buyer (i.e., one cardholder). 
Each approval incurs a fee, relative to the total invoice amount. If an invoice is larger tlian tlie 
approved amount (e.g., due to taxes or shipping fees), a 2!4% fee (or more depending on length of 
terms) may be automatically charged agamst the extra amount. 
Receive Invoice 

30 After shipping tlie goods, the vendor sends the invoice to both the cardholder and to the 

card issuer. After the card issuer receives invoice(s), each invoice is marked with the 
authorization code. The invoice specifies the payment terms. Depending on the payment terms, a 
selected fee may be charged by the card issuer for the service of guaranteeing the total approved 
amount. In one embodiment, the fees are accessed on the basis of the total invoice amount, 

35 including tax and shipping charges. 
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In one embodiment, the fee schedule varies according to the length of time until the 
payment is due. The following table illustrates an exemplary fee schedule. 



Payment Terms 


Fee 


Net 30 


254% 


Net 60 


214% 


Net 90 


3% 


Net 120 


3'>4% 


Net 150 


4% 


Net 180 


414% 



If more than one invoice is received from a vendor, the vendor should include a summary 
5 sheet having totals for verification. 

The card issuer inputs an authorization code to fmd the transaction in the database, and 
then inputs the invoice number and total. The card issuer logs the invoice and sends the invoice to 
the guarantor of the transaction both physically and as an electronic item. 
Guarantor Receives Payments 

10 Payments are received by the guarantor, which sends an electronic log of settlements to the . 

card issuer. It is noted that in one embodiment, the buyer sends the payments directly to the card 
issuer. The system creates the appropriate payment transactions and computes the guarantor's 
fee, creating a transaction object in the platform for that as well. The card issuer applies 
payments to the invoice. The guarantor takes a fee, based on the total amount of the invoice, and 

IS then send the payments on to the card issuer. One payment may be applied to multiple invoices. 
A partial payment may be applied to an invoice. 

The card issuer distributes to the vendor the payment, less fees any transaction fees. The 
vendor receives the payment, less fees, based on the total amount of the INVOICE (not the 
amount received). The vendor may bill the buyer for the difference between the total invoice and 
20 the amount remitted. In the event the payment is less than the total invoice amount due to 
payment terms (e.g., 2%/10 Net 30), the vendor is responsible for issuing a credit for the buyer. 

Card Issuer Issues Vendor Checks 

A payables batch is created in the system. After editing, the batch is sent to a A/P system 
to actually print checks. Optionally, the card issuer can print the checks. 

25 
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Cycle End Processing 

The vendors each receive a cycle-end statement summarizing all transactions and 
providing updated information. This marks a regular contact point, where marketing materials 
may be included with the mailing. Some may elect to receive such transmissions electronically, 
5 e.g., CD-ROM, diskette, ftp, email. 
Issue Cards (Batch. Single. Re-issued 

Cards may be issued in large batches, sent out for embossing, or one at a time. 
Buver Credit Advance 

The buyer is responsible for paying for the goods and services that have been purchased 
10 from the seller within a predetermined time period, e^,, 30, 60, 90 days. In one embodiment, the 
start of the due date tune period is triggered after the seller transmits the goods to the buyer or, 
alternatively, after the seller performs services for the buyer. 

In one embodiment of the invention, the buyer may defer payment by paying a selected 
fee. In return, the recipient of the selected fee pays all or some of the fiinds that are owed by the 
15 buyer. 

For example, with respect to the system shown in Fig. IB, the buyer may request the credit 
vendor to defer payment to the re-factor company. In exchange for receiving the selected fee, the 
credit vendor pays the seller after the predetermined time period. Also, the credit vendor transmits 
a selected fee to the re-factor company for the re-factor company's involvement with the initial 
20 transaction between the buyer and the seller. Alternatively, instead of the credit vendor, the re- 
factor company can accept delayed payment and in return for the delayed payment, charge the fee 
and pay the credit vendor prior to the expiration of the predetermined time periods, e.g., 30, 60, 90 
days. Hie credit vendor then pays the seller the monies owed the seller by the buyer minus any 
transaction fees. 

25 Furthermore, for example, with respect to the system shown in Fig. IC, the buyer may 

request the credit vendor to receive delayed payment for a fee. In return for the fee, the credit 
vendor pays the seller prior to the expiration of the predetermined time period. 
View Accounts 

In one embodiment, buyers and sellers may retrieve their account information from the 
30 credit server. Account information can include: credit limits, past transactions, billing information, 
etc. In this embodiment, the credit vendor maintains a server computer that is operably connected 
to a network. The network may include any type of electronically comiected group of computers 
including, for instance, the following networks: Internet, Intranet, Local Area Networks (LAN) or 
Wide Area Networks (WAN). In addition, the connectivity to the network may be, for example, 
35 remote modem, Ethernet (IEEE 802.3), Token Ring (IEEE 802.5), Fiber Distributed Datalink 
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Interface (FDDI) or Asynchronous Transfer Mode (ATM). Note that computing devices may be 
desktop, server, portable, hand-held, set-top, or any other desired type of configuration. As used 
herein, an Internet includes network variations such as public internet, a private internet, a secure 
internet, a private network, a public network, a value-added network, an intranet, and the like. 
S Using a client computer that is connected to the network, the client computer can retrieve 

account information. An exemplary report showing account information is shown in Figure 41. In 
one embodiment, the server computer allows the user to contest certain transactions that are 
identified in the account information. Upon contesting a transaction, the contesting party is 
afforded an opportunity to associate one or more messages with the contest. In this regard, each 

10 transaction has an electronic storage bin to hold communications between the buyer and the seller 
for the selected transaction. 

In one embodiment, if the transaction is contested by the buyer, the message is 
automatically transmitted via electronic mail to an agent for the seller and stored in the electronic 
storage bin. Furthermore, in one embodiment, if the transaction is contested by the seller, the 

15 message is automatically transmitted via electronic mail to an agent for the buyer and stored in the 
electronic storage bin. Once received by the non-contesting party, the contesting party is 
presented with an opportunity to reply via electronic mail. Using the storage bin, the 
communication history between tlie buyer and seller may be reviewed. Furthermore, in one 
embodiment of the invention, the non-contesting party can change the terms of the transaction to 

20 end the dispute. 

In one embodiment of the invention, a buyer is afforded an opportunity to delay payment 
with respect to one or more of the transactions. In this embodiment, when the user views their past 
transactions, the buyer is presented a selectable icon proximate to each of the transactions for 
which that buyer owes payment. By selecting the selectable icon, the user indicates a request to 

25 extend the due date for paying the due fees. In response to the selection, the server computer 
adjusts the due date for the transactions and assigns a due date extension fee to the buyer's account. 
Furthermore, at a predetermined point, the server computer pays the seller the monies that are 
owed to seller by the buyer. 

In another embodiment of the invention, a seller is afforded an opportunity to receive 

30 payment prior to agreed upon terms with the credit vendor. In this embodiment, when the seller 
views past transactions, the seller is presented with a selectable icon proximate to each of the 
transactions in which the seller is to receive payment. By selecting the selected icon, the seller 
indicates a request to receive payment for the funds immediately. In response to the selection, the 
server computer pays the seller the monies owed minus an advance fee. 
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It is noted that since a buyer may also be a seller to other buyers, the buyer and seller 
reporting screens may be integrated into a single screen display. 

System Description 

Attention is now directed to the figures. Fig. 1 A is a flow diagram of a first embodiment 
S of the invention showing the purchase and fulfillment between a buyer, vendor and guaranteeing 
financial institution using the method of the invention. Referring to Fig. I, the buyer makes a 
purchase from the vendor with a guaranteed credit Ime as established in the profile database 10. 
The purchase order is then being forwarded to the vendor for fulfillment 12. Then the receivable is 
reassigned to the guaranteeing financial mstitution for a guarantee of the receivables 14, the 

1 0 purchase order is returned to the buyer for the buyer's records 16. The vendor ships the order with 
a copy of the invoice and terms back to the buyer 18, for example, net 30, net 60, or net 90. Then 
the vendor sends shipment confirmation and a copy of the invoice to tlie platform for the 
invention, which in one embodiment,, is entitled "ProfitScape" (hereinafter referred to as tlie 
platform), on an e-commerce web site 20. Next the buyer makes payment to the platform based 

15 upon the vendor terms 22, and the platform forwards payment to the vendor 24, minus a negotiated 
percentage. The platform profile database maintains credit records and transfers all monies from 
the buyer to the vendor minus a negotiated percentage or transaction fee, for example 8-12% of the 
transaction. The guaranteeing financial institution will review the accounts periodically, for 
example every 90 days, for buyer credit line limits. Also periodically, for example every 30 days, 

20 the platform reconciles with the guaranteeing financial institution for a percentage of all gross 
revenue of the platform's guaranteed electronic commerce transactions. 

Fig. IB is another embodiment of the invention. Fig. IB is a flow diagram of a second 
embodiment of the invention showing the purchase and fulfillment between a buyer, seller and a 
credit vendor. It is noted that although only one buyer is shown, the electronic platform can be 

25 used in connection with large numbers of buyers. 

Referring to Fig. IB, ait a step 51, a buyer provides credit information via an application to 
a credit vendor. Next, at a step 52, the credit vendor forwards the information to a re-factor 
company. The re-factor company evaluates the credit information and determines a credit limit for 
the buyer. At a step 53 the re-factor company transmits the credit limit for the buyer to the credit 

30 vendor. Continuing to a step 54, the credit vendor transmits one or more cards to the buyer. In one 
embodiment, the card has an electronic strip having a magnetically imprinted card number. 
Furthermore, the card may have an associated personal identification number. 

Moving to a step 55, the buyer contacts a seller and offers to purchase goods or services 
that are provided by the seller. At the step 55, the buyer provides the seller their card or 

35 alternatively the buyer' s account information. 
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Next, at a step 56, the seller provides the credit vendor, via a transaction device, the 
transaction information. The transaction device can include: a computer, a hand held device, a 
cash register, or other electronic device. In one embodiment of the invention, the transaction 
information comprises a merchant identifier, the buyer account number (the card number), the 
S name on the card, an expiration date that is associated with the card, and an estimated transaction 
amount. 

The credit vendor determines whether the transaction amount would cause the buyer to 
spend m excess of the buyer's credit limit. Assuming the buyer has sufficient credit, the process 
moves to a step 57 wherein the credit vendor transmits approval to the seller computer for the 
10 transaction. Furthermore, the credit vendor records the transaction information to facilitate 
evaluating further purchases of the buyer. 

Continuing to a step 58, the seller ships the goods or performs the services specified by the 
contract. In return, the seller receives from the credit vendor the right to receive payment no later 
than a predetermined period. In one embodiment of the invention, the predetermined period is no 
15 later than 1 80 days or whenever the re-factor company receives payment; whichever is sooner. 

Next, at a step 61, the buyer makes payment to the re-factor company. Continuing to a 
step 62, the re-factor company pays the credit vendor minus a first transaction fee. Proceeding to a 
state 63, the re-factor company pays the seller minus a second transaction fee. It is noted that in 
one embodiment of the invention, for a predetermined fee, the seller can borrow against tlie 
20 guaranteed received payment. 

Fig. IC is a flow diagram of a third embodiment of the invention showing the purchase and 
fulfillment between a buyer, vendor and guaranteeing financial institution. It is noted that although 
only one buyer is shown, the invention can be used in connection with large numbers of buyers. 

Referring to Fig. IC, at a step 71, a buyer provides credit information via an application to 
25 a credit vendor. Next, at a step 72, the credit vendor forwards the information to a credit insurer. 
The credit insurer evaluates the credit information and determines whether it will insure the 
transaction. At a step 73, the credit insurer transmits the credit limit for the buyer to the credit 
vendor. The credit vendor may transmit one or more cards to the buyer. 

Moving to a step 74, the buyer contacts a seller and offers to purchase goods or services 
30 that are provided by the seller. Upon agreeing to the terms of a deal, the buyer provides the seller 
their card or alternatively provides the buyers account information. 

Next, at a step 75, the seller provides the credit vendor, via a transaction device, the 
transaction information. In one embodiment of the invention, the transaction information 
comprises a merchant identifier, the buyer account number (tlie card number), the name on the 
35 card, an expiration date that is associated with the card, and an estimated transaction amount. 
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The credit vendor determines whether the transaction amount would cause the buyer to 
spend in excess of the buyer's credit limit. Assuming tiie buyer has sufficient credit, the process 
moves to a step 76 wherein the credit vendor transmits approval to the seller's transaction device. 
Furthermore, the credit vendor records the transaction information to facilitate evaluating further 
S purchases of the buyer. 

Continuing to a step 77, the seller ships the goods or performs the services specified by the 
contract In return, tlie seller receives from the credit vendor the right to receive payment no later 
than a predetermined period. In one embodiment of the invention, the predetermined period is no 
later than 180 days or whenever the credit vendor receives payment, whichever is sooner. 

10 Next, at a step 78, the buyer makes payment to the credit vendor. It is noted that in one 

embodiment of the invention, for a predetermined fee, the seller can borrow against the guaranteed 
received payment. Moving to a step 79, the credit vendor pays the seller. Fig. 2 is another 
embodiment of the invention. In Fig. 2, the buyer makes a purchase through the guaranteeing 
financial institution with a guaranteed credit line 26. In one embodiment, the vendor then obtains 

IS from the guaranteeing financial institution an authorization code for the amount of the intended 
purchase, including tax and shipping if known. Once authorization is obtained (usually within 
seconds), the vendor may ship the order knowing that payment is guaranteed. The purchase order is 
then forwarded to the vendor for fulfillment 28 and the purchase order is then returned to the buyer 
for the buyer's records 30. Then the vendor ships the order with a copy of the invoice and terms to 

20 the buyer 32, and the vendor sends shipment confirmation and a copy of the invoice to the 
guaranteeing financial institution 34. In one embodiment, the vendor notes on the buyer's copy of 
the invoice to remit payment to the guaranteeing financial institution 34. The buyer the makes 
payment to the guaranteeing institution based upon the vendor's terms 36, and the institution 
forwards payment to the vendor minus the institution's negotiated percentage 38. 

25 Fig. 3 is a block diagram demonstrating the post-shopping experience of the buyer using 

the methodology of the invention. The user flrst shops and then views their order, and before 
checking out, chooses a form of payment, be it either a credit card, or through the platform of the 
invention. If a credit card is chosen as the method of payment, the transaction proceeds tlirough 
the platform of the invention. If the user is enrolled in the platform of the invention, their 

30 transaction is guaranteed. The user is also offered the choice of joining and becoming a member of 
the platform. 

Fig. 4 shows the process that a user proceeds through when first logging on to the platform 
of the invention. First the existing customer or the new user visits the web site having the 
platform of the invention 40. The new user applies for membership and a line of credit with 
35 guaranteed receivables 42. An existing user is shown logging in with their user name and 
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password 44, and the existing customer or new user is forwarded to the appropriate web sites for 
purchases 46. Applications for credit and guarantees are forwarded to the financial institution for 
review 48. If the application for credit has been denied, the customer is then notified 50. If the 
application for credit has been approved, the customer is assigned a guaranteed credit limit 52, as 
5 well as an *TD" and is then entered into the user profile database. 

Fig. 5 is a block diagram demonstrating an approved customer 54 being forwarded to 
customer service so that customer service can gather information 56 and create a user database 
profile on their company, products, target market, history, terms, etc. Example data collected for 
the user's profile includes: name, address, contact information, primary industry, credit insured 

10 amount, payment history, credit usage, target marketplace, products offered, services offered, 
inventory, buying trend data, and Internet usage data. 

Fig. 6 is a block diagram demonstrating a user searching the profile database. A user 
queries the database through a search engine for specific information 58. Data is searched from the 
database and returned to the user 60. Then the user accesses a web site from a returned data link 

15 62, and the user consummates an electronic commerce transaction 64 such as that shown in Fig. 1 . 

Fig. 7 shows the algorithm metliods for the various embodiments of the invention. In Fig. 
7a the buyer, seller, and guaranteeing institution cannot communicate with each other but only with 
the platform for the invention. In Fig. 7b the buyer and seller only communicate with tlie 
guaranteeing institution and not with each other. In Fig. 7d the buyer and guaranteeing institution 

20 can each only communicate with the seller, but the seller can communicate with either or both of 
the buyer and guaranteeing institution. In Fig. 7e the seller and the guaranteeing institution can 
each only communicate with the buyer, but the buyer can communicate with either or both of them. 

Fig. 8 shows a flow diagram of an embodiment of the invention wherein the method of the 
invention includes an international licensee. First a user applies for a credit line through the 

25 international licensee 66. Tlien an application is entered into the database of the invention 68, and 
that application is forwarded to the guaranteeing financial institution 70. Then the applicant who is 
approved is assigned a line of credit and a user ID, and the database is tlien updated with their 
information 72. The user and licensee are then notified 74. At this point, the process proceeds as 
shown in Fig. 9. If the application is denied, the applicant and licensee are notified accordingly 76. 

30 Fig. 9 demonstrates the process that proceeds after the applicant has been approved in Fig. 

8. The international buyer accesses the marketplace through a licensee 78. Then the platform's 
buyer makes an international purchase on the platform witli the user's ID 80. Next the user ID and 
credit availability are checked through the database and the guaranteeing fmancial institution 82 
and 82'. Then the seller receives the order with the guaranteed receivables 84, and the transaction 

35 has been completed and the order is shipped to the buyer 86. 
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Fig. 10 is a flow diagram for a second embodiment of the international licensee application 
of the invention. First the user applies for a credit line through an internationallicensee 88. Then 
the application is forwarded to the guaranteeing financial institution 90, If the application is 
approved, the applicant is then assigned a line of credit and a user ID 92. The user and licensee are 
5 then notified. At this point, the process proceeds as shown in Fig. 11. If the application is denied, 
the applicant and licensee are accordmgly notified 94. 

Fig. 1 1 represents the next stage in the process after having completed those steps in Fig. 
10. In Fig. 11, the international buyer accesses the marketplace through a licensee 96 and the 
platform buyer makes an international purchase 98 on the platform of the invention with the user 
10 ID. Then the user ID and credit availability are checked through the guaranteeing financial 
institution 100. The seller receives the order with the guaranteed receivables 102, the transaction is 
completed and the order is shipped to the buyer 104. 

Fig. 12 is a third embodiment of the international licensee application of the invention. In 
Fig. 12, the guaranteed buyer makes a purchase fix)m a vendor on an international licensee 
15 platform 106. Then the user ID and password are passed to a module 108 which allows the 
communication witli the database of the invention, and the ID and credit availability are checked 
through the database, as well as the guaranteeing financial institution 110 and 110'. The vendor 
web site receives verification 112, and the transaction is completed and the order is then shipped to 
the buyer 114. 

20 Fig. 13 is a fourth embodiment of the international licensee application of the invention 

wherein the communication occurs directly with the guaranteeing financial institution. First, the 
guaranteed buyer makes purchases from a vendor on the international licensee platform 116. Then 
the user ID and password are passed to a module which allows communication with the database of 
the invention 118. Next tlie user ID and credit availability are checked through the guaranteeing 

25 financial institution 120. The vendor web site receives verification 122, and the transaction is 
completed and the order is then shipped to the buyer 124. 

Fig. 14 is a flow chart demonstrating vendors' direct marketing to existing registered users 
(buyers) of the invention. The buyer logs on and sees offers being retrieved from the database, 
and chooses whether or not to accept the offer. If the offer is accepted, the transaction is 

30 concluded. If the offer is not accepted, the user continues on through the web site. The vendor 
creates offers and then sends them to the database for storage. The vendor then creates a user 
profile from the information off of the database. The database then compares the profile created by 
the vendor with existing customer profiles. The invention then creates a list of matching users 
who wish to see offers of this type and proceeds to offer them to those users the next time that they 

35 log on. 
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Fig. IS is a flow chart showing the user applying for credit with the methodology of the 
invention. The user first applies for a credit line, and that information is then added to the 
database. The information is then submitted to a financial institution and the financial institution 
either approves or disapproves the credit application. If the application is not approved, the user is 
5 informed of the result. If the application is approved, the amount of credit is recorded for the user 
and the user is accordmgly informed of approval and the amount of credit. For example, an 
applicant applies for a "net 30 card." This card is similar in appearance to a credit card. Should 
the applicant be approved for the net 30 card, then they will be able to purchase goods and services 
immediately, and upon receipt the guaranteeing mstitution or platfonn of the invention will 

10 guarantee payment within thirty days to the vendor. The applicant can apply for the card either 
manually or electronically. Information received firom the candidate is then entered into a database 
which is forwarded to a guaranteeing financial institution. The guaranteeing financial institution 
then reviews the application information and issues an insured line of credit if the applicant is 
approved. Once the applicant is approved, the guaranteeing financial institution notifies the 

IS platform of the insured credit line and guarantees payment of receivables. Then the net 30 card is 
issued to the applicant, who is now a registered user of the platform of the invention. The user's 
transactions are then checked through the platform profile database for available credit and 
amounts adjusted. At the end of each day, the platform of the invention keeps the guaranteeing 
financial institution updated on ail user accounts' status. This methodology insures the vendor's 

20 receivables. 

Fig. 16 is a flow chart demonstrating the steps that a user proceeds through in logging on 
to the web site containing the platform of the invention. The user first arrives at the public Web 
site and enters their login ID. The site then compares their ID and password to those recorded in 
tlie database. If the log-in is not valid, then the user is refused access and is returned to the public 

25 Web site. If the log-in is valid, then the user preferences are retrieved from the database and are 
customized to provide a personalized page displayed to the user. The user then continues with 
member-only options within the system. 

Fig. 17 is a flow chart demonstrating a user making a purchase using the methodology of 
the invention. TTie user first attempts to conclude the transaction and the platform of the 

30 invention ascertains the user's identity and compares their transaction with an available credit 
balance stored in the database. If their available balance is not adequate, then the transaction is 
denied. If the available balance is adequate, then the transaction proceeds and the invention 
subtracts the transaction total from the available balance, and the order is confirmed to Hie user, the 
vendor is notified of the purchase order, and the user receives a copy of the purchase order. Next, 

35 the receivables are reassigned to the financial institution and the vendor receives notification of the 
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purchase order and fulfills the purchase order. Once the receivables are reassigned to the financial 
institution, then the financial institution receives notification of that reassignment. Once the 
vendor notifies the platform of the fulfilhnent of the order and has sent the user the merchandise, 
the user is then billed. If the user does not pay the bill, then the financial institution is notified who 
S dien pays the platform who in turn pays the vendor. If the user does pay tlie bill, then their 
payment is added to the available credit in their account. 

Fig. 18 is a flow diagram of a third embodiment of the invention. First the buyer selects 
the platform guaranteed receivables method as the method of payment 126. The e-commerce 
backend forwards purchase information to the platform profile database 128. Available credit is 

10 checked from the user's profile and new applicants are processed 130. Then the profile database is 
updated accordingly 132. The buyer is notified and if approved, the vendor, or seller, is also 
notified to ship 134 and 134'. Then the buyer makes payment to the guarantor bank according to 
the terms set forth by the vendor, or seller 138. The profile database is then updated accordingly 
140. The guarantor bank processes the payment and forwards payment to the platform and vendor 

15 bank 142. Then the vendor bank credits the vendor, or seller 144. 

Fig. 19 is a flow diagram of a fourth embodiment of the invention. In this embodiment, 
the buyer selects the platform guaranteed receivables method as the method of payment 146. The 
e-commerce backend forwards purchase information to a processor 148. The processor forwards 
information to the guaranteed receivables issuer which is the platform of the invention 150. Then 

20 the available credit is checked, new applicants are processed, and the profile database is updated 
accordingly 152. The buyer is notified of either approval or rejection of tlieir application 154. If 
approved, the vendor, or seller, is notified to ship. The buyer makes payments to the guarantor 
bank lock box according to the terms set forth by the vendor, or seller 156. Next, the database and 
credit limit are updated accordingly 158. Then the guarantor bank processes payment and 

25 forwards payment to the platform and vendor bank 160. Then the vendor bank credits the vendor 
162. 

Figs. 20-40 furtlier illustrate the invention as noted in the brief figure descriptions, above. 
The embodiments presented in the figures are not meant to limit the applications of the invention. 
The methodology of the invention has application in buying and selling, as well as lending based 
30 upon accounts receivables, in addition to credit insuring purchases. 

Abstract Model 

The platform comprises one or more computer implemented modules. As can be appreciated 
by one of ordinary skill in the art, each of the modules comprise various sub-routines, procedures, 
definitional statements, and macros. Each of the modules are typically separately compiled and 
35 linked into a single executable program. The modules may be arbitrarily redistributed to one of the 
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other modules, combined together in a single module, or made available in a shareable dynamic link 
library. Optionally, as can be appreciated by one skilled in the art, one or more of the modules may 
be designed using hardware. 

The modules may be written in any programming language such as C, C++, BASIC, 
5 Pascal, Java, and FORTRAN and ran under the well-known operating system. C, C++, BASIC, 
Pascal, Java, and FORTRAN are industry standard programming languages for which many 
commercial compilers can be used to create executable code. 

The following sections describe exemplary software-implemented classes that may be 
defined by selected ones of the modules. 
10 Company 

The company class provides a common base class for the four types of companies involved 
in the system: Merchants, Cardholders, Factors, and Guarantors. 



id: int 


System generated identification number. 


mdustryCode; Code 


Type of industry the company belongs to. 


names: List of CompanyName 


Companies have a primary name and zero or 
more DBA's. 


addresses: Map of List of Address 


Companies have one or more addresses. Each 
address is marked as to its usage. 


contacts: Map of List of Contact 


Companies have one or more contacts. Each 

contact is marked as to its usage. 


taxID: Biglnteger 


Federal tax id or VAT code. 






int getlDO 


Get the company identification number. 


Code getlndustryCode Q 


Get the industry code. 


void setlndustryCode (Code newlndustry) 


Set the industry code. 


Iterator gefNames 0 


Get an iterator over the list of names, in 
sequence. The first is the primary, any 
subsequent are DBA's. 


Iterator getDBANames () 


Get an iterator over just the DBA's. 


Iterator getAddresses () 


Get an iterator over all addresses, sorted by type 

by sequence. 


Iterator getAddresses (Code addressType) 


Get an iterator over all addresses of the 
specified type sorted by sequence. 


Iterator getContacts () 


Get an iterator over all the contacts, order by 
type by sequence. 


Iterator getContacts (Code contactType) 


Get an iterator over all contacts of the given 
type, order by sequence. 


Biglnteger getTaxID 0 


Get the tax id or VAT number. 



15 Code 

The Code class represents all iields that store a coded value, referenced within the Codes 

table. 
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codeType: String 




codeName: String 




codeCharacterValue: String 




codelntegerValue: long 




description: String 





CompanvName 

CompanyName represents a single company name, which may be one of many names a 
company goes by. 



CompanyName 



name: String 



The company name. 



Address 



Address provides a postal address. 



Address 


type: Code 


The address type. 


linel: String 


Number and street, etc. 


line2: String 


Overflow. 


lineS: String 


Overflow. 


city: String 




stateCode: Code 




postaiCode: Bigjnteger 




countryCode: Code 




attention: String 





10 Contact 



The Contact class represents a person and their contact information as well as a company's 
primary contact information. 



Contact 


type: Code 




lastName: Strmg 




firstName: String 




middleName: String 




jobTitle: String 




department: Strmg 




url: String 




email: String 




phone: String 




fax: String 




mobile: String 




pager: String 




notes: String 




address 1: String 
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address2: String 




address3: String 




city: String 




stateCode: Code 




postalCode: Biglnteger 




countryCode : Code 





Merchant 

The Merchant class provides information regarding a single merchant within the system. 



5 MerchantHome 

The MerchantHome class provides methods for creating, finding, and deleting Merchants. 



MerchantHome 


create (...) 


Create a new Merchant. 


findByPrimaryKey (MerchantPK pk) 


Find by primary key. 


Name[] getNexfNames (Name jSrst, int 
count) 


Get a list of names greater than or equal to the 

given one. 


NameQ getPreviousNames (Name last, int 
count) 


Get a list of names less than or equal to the 
given one. 



Cardholder 



The cardholder class represents a single cardholder within the system. 



Cardholder extends Company 


guarantorlD: GuarantorPK 


The guarantor issuing this line of credit. 


limit: BigDecimal 




limitDate: Date 




limitSource: String 




customerlD: String 




association: AssociationPK 




source: String 




creditStatus: Code 





10 

CardholderHome 

The CardholderHome class provides methods for creating, finding, and deleting 
Cardholders. 



CardholderHome 


create (...) 


Create a new Cardholder. 


findByPrimaryKey (CardholderPK pk) 


Find by primary key. 


NameQ gefNextNames (Name first, int 
count) 


Get a list of names greater than or equal to the 

given one. 


Nanie[] getPreviousNames (Name last, int 
count) 


Get a list of names less than or equal to the 
given one. 



15 
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Card 


limit: BigDecimal 




limitDate: Date 




limitSource: String 




PIN: String 




name: String 




companyName: CompanyName 


Whicli company name is on the card, it preferably is 
one of the defined ones. 


allianceName: CompanyName 


An alliance name if any. 


issueDate: Date 




expireDate: Date 




badgeNumber: String 





Guarantor 



Guarantor extends Company 


minimum: BigDecimal 




feePercentage: BigDecimal 





GuarantorHome 

The GuarantorHome class provides methods for creating, finding, and deleting Guarantors. 



GuarantorHome 



same as MerchantHome 



15 



10 Factor 

The factor class represents a single factor. 



FactorHome 

The FactorHome class provides methods for creating, finding, and deleting Factors. 
Association 

The Association Class represents a company with a business relationship. 



20 AssociationHome 

The AssociatonHome class provides methods for creating, finding, and deleting associations. 

Transaction 

25 The transaction class represents a transaction. 



Transaction 


id: String 




timestamp: Timestamp 




companylD: CompanyPK 




company2ID: CompanyPK 




type: Code 
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amount: BigDecimal 




batchID: String 





TransactionHome 

The TransactionHome class provides methods for creating, finding, and deleting 
Transactions. 

5 Various other classes may be used to represent other portions of the system such as 

merchant invoices, cardholder payment, and a merchant statement/check. 

Although the invention has been described in detail vntti particular reference to these 
preferred embodiments, other embodiments can achieve the same results. Variations and 
modifications of the invention will be obvious to those siciiled in the art and it is intended to cover 
10 in the appended claims all such modifications and equivalents. The entire disclosures of all 
references, applications, patents and publications cited above are hereby uicorporated by reference. 
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Database Schema 

It is noted that a number of different database schemas may be used with respect to the 
platform profile database. Set forth below are exemplary tables that may be used in conjunction 
with one embodiment of the platform profile database. 

Table 1: System Users 

CREATE TABLE SYSTUSR 
( 



ID 


INTEGER NOT NULL, 




{ 


unique id 


) 


LGNID 


CHAR (15) NOT NULL, 




{ 


Igin id 


} 


CDUSRID 


INTEGER NOT NULL, 




{ 


user class 


) 


FWD 


CHAR (15) NOT NULL, 




{ 


password 


) 


PWDDT 


DATE NOT NULL, 




{ 


password date 


) 


NAM 


CHAR (50) NOT NULL, 




{ 


£ull name 


) 


ACT 


CHAR(l) MOT NULL, 




{ 


active Y/N 


} 


LGNCNT 


INT NOT NULL, 




{ 


login count 


) 


LGNBAD 


INT NOT NULL, 




{ 


login bad count 


) 


LGNDTTM 


OATETIME YEAR TO SECOND, 


{ 


last login date } 


ATDTTM 


DATETXME YEAR TO SECOND, 


{ 


last login attmp } 


ACTDT 


DATE, 




1 


active date 


) 


EXPDT 


DATE, 




{ 


expire date 


> 


DTA 


CHAR(50) , 




{ 


any data to associate to user } 


CRTUSRXD CHAR (15) NOT NULL, 




{ 


create user id 


) 


CRTDTTM 


DATETIME 




{ 


create datetime 


} 




YEAR TO SECOND NOT 


NULL, 








CRTSRVR 


CHAR (15) NOT NULL, 




{ 


create server 


} 


CRTCLNT 


CHAR (15) NOT NULL, 




{ 


create client 


) 


CHGUSRID CHARdS) NOT NULL, 




{ 


change by user 


} 


CHGDTTM 


DATETIME 




{ 


change datetime 


} 




•YEAR TO SECOND NOT 


NULL, 








CHG5RVR 


CHAR (15) NOT NULL, 




{ 


change server 


} 


CHGCLNT 


CHAR (15) NOT NULL, 




{ 


change client 


} 
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PRIMARY KEY (ID) CONSTRAINT SYSCUSRFK, 
CHECK (ACT IN CY', 'NM) CONSTRAINT SYSCUSRl, 
DNZQUE(L6NID) CONSTRAINT SYSCU5R2 
) I.OCK MODE ROW; 



CREATE TABLE SYSTUSRG 
( 

ID INTEGER NOT NULL, 

DSRID INTEGER NOT NULL, 
GRPUSRID INTEGER NOT NOLL, 



Table 2: User Groups 
(Map a user to a set of zero or more groups) 

{ unique id } 
{ user id ) 
{ group user id } 



PRIMARY KEY (ID) CONSTRAINT SYSCUSRGPK, 
UNIQUE (USRID, GRPUSRID) CONSTRAINT SYSCUSRGI, 

FOREIGN KEY(USRID) REFERENCES SYSTUSR(ID} CONSTRAINT SYSCUSRGFKl, 
FOREIGN KEY (GRPUSRID) REFERENCES SYSTUSR(ID) CONSTRAINT SYSCUSRGFK2 



CREATE TABLE SYSTMNU 



Table 3: System Menu 



ID INTEGER NOT NULL, 

TYP CHAR(l) NOT NULL, 

FNAM CHAR (100). 

PNAM CHAR (100), 

DESC CHAR (100) NOT NULL, 

MNUID INTEGER, 



{ unique id ) 

{ M = Menu, F a Function, L * Link ) 
{ public alias for program } 

{ program name } 
{ human description of function ) 
{ parent menu } 



PRIMARY KEY (ID) CONSTRAINT SYSCMNDPK, 

FOREIGN KEY(MNUID) REFERENCES SYSTMNU(ID) CONSTRAINT SYSCMNUFKl, 
CHECK (TYP IN ('M', »F', "LM) CONSTRAINT SYSCMNUl 

) LOCK MODE ROW; 
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CREATE TABLE SYSTUSRP 



Table 4: User Permissions 



ID INTEGER NOT NULL, 

MNUID INTEGER NOT NULL, 

USRID INTEGER NOT NULL, 

PRM CHAR(l) NOT NULL, 



{ unique id } 

{ menu Id } 

{ user id } 

{ N B No Access, R a Read, F b Full } 



PRIMARY KEY (ID) CONSTRAINT SYSCUSRPPK, 
UNIQUE (MNUID, USRID) CONSTRAINT SYSCUSRPl, 

FOREIGN KEY (MNUID) REFERENCES SYSTMNU{ID) CONSTRAINT SYSCUSRPFKl 



) LOCK MODE ROW; 

Table 5: Unique IDs 

CREATE TABLE SYSTID 
( 

NM CHAR (20) NOT NULL, 

LSTID INT8 NOT NULL, 



FRIt4ARY KEY(NM} 
) LOCK MODE ROW; 

Table 6: Authorization Responses 

CREATE TABLE N30TCDRSP 
( 

ID INTEGER NOT NULL, 

DESC CHAR (20) NOT NULL, 



PRIMARY KEY (ID) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

Tabic 7: Application Status 

CREATE TABLE N30TCDAST 
t 

10 INTEGER NOT NULL, 
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PRIMARY KEY (ID) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

TableS: Paymeor Terms 

CREATE TABLE N30TCDFMT 
( 

ID INTEGER NOT NULL, 

DESC CHAR (20) NOT NULL, 
FEB DECIMAL (8, 4) NOT NULL, 

PRIMARY KEY (ID), 
UNIQUE (DESC) 
) LOCK MODE ROW; 

Table 9: Transaction Types 

CREATE TABLE N30TCDTRN 
( 

ID INTEGER NOT NULL, 

DESC CHAR(20) NOT NX7LL, 

PRIMARY KEY (ID) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

Table 10: Transaction Detail Types 

CREATE TABLE N3 0TCDTRND 
( 

ID INTEGER NOT NULL, 

DESC CHAR (50) NOT NULL, 
BADJ MONEY (14, 2) NOT NULL , 
CADJ MONEY (14, 2} NOT NULL , 

PRIMARY KEY (ID) , 
UNIQUE (DESC) 
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Table 11: lodustry Codes 

CREATE TABLE N30TCDIND 
< 

ID INTEGER NOT NULL, 

DESC CHARCSO) NOT NULL, 

PRIMARY KEY (ID) , 
tnriQUE (DESC) 
) LOCK MODE ROW; 

Table 12: US State Codes 

CREATE TABLE N30TCDUSS 
( 

CD CHAR (2) NOT NtJLL, 

DESC CHAR (20) NOT NULL, 

PRIMARY KEY (CD) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

Table 13: ISO 3166 Country Codes 

CREATE TABLE N30TCD3166 
( 

CD CHAR (2) NOT NULL, 

DESC CHAR (20) NOT NULL, 

PRIMARY KEY (CD) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

Table 14: Contact Type Codes 

CREATE TABLE N30TCDCON 
( 

ID INTEGER NOT NULL, 

DESC CHAR (20) NOT NULL, 

PRI CHAR(l) NOT NULL CHECK (PRI IN ('Y', 'NM), 
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PRIMARY KEY (ID) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

CREATE TABLE N30TCDCHCS 
( 

ID INTEGER NOT NULL, 

DESC CHAR (20) NOT NULL, 
AUTH CHAR(l) NOT NULL, 

PRIMARY KEY (ID) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

CREATE TABLE N30TCDCHS 
( 

ID INTEGER NOT NULL, 

DESC CHAR (20) NOT NULL, 
AUTH CHARd) NOT NULL, 

PRIMARY KEY (ID), 
X7NIQUE (DESC) 
) LOCK MODE ROW; 

CREATE TABLE N30TAPP 
( 

ID INTEGER NOT NULL, 

CH CHARACTER (1), 

EMAIL CHARACTER (30) , 

FNAM CHARACTER (30) , 

LNAM CHARACTER (30), 

MNAM CHARACT6R(30) , 

CPNAM CHARACTER (40) , 



Table 15: Card Status 



Table 16: Credit Status 



Table 17: Credit Application 
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PHO CHAPACTER(20) , 

FAX CHARACTER (20) , 

ADRl CHARACTER (30) . 

ADR2 CHARACTER (30) , 

ADR3 CHARACTER (30) . 

CTY CHARACTER (25) , 

ST CHARACTER (2) , 

ZIP CHARACTER (10) , 

CTRY CHARACTER (2 ) , 

BFNAM CHARACTER (30) , 

BLNAM CHARACTER (3 0) , 

BPHN CH7mACTER(20) , 

BADRl CHARACTER (30) , 

BADR2 CHARACTER (30) , 

BADR3 CHARACTER (30), 

BCry CHARACTER ( 25 ) , 

BST CHARACTER (2) , 

BZIP CHARACTER (10) , 

BCTRY CHARACTER (2 ) , 

OFF CHARACTER (30) , 

OFFT CHARACTBR(30) , 

CON CHARACTER (30), 
CDINDID INTEGER NOT NULL, 

DUNS CHARACTER (20), 

DBA CHARACTER (30), 

PCPY CHARACTER (30), 

TAXID CHARACTER ( 20) , 

ASLS CHARACTER(20) , 

EDATE CHARACTER (20), 

LOGS CHARACTER ( 5 ) , 

EMPS CHARACTER ( 5 ) , 

TBUS CHARACTER(20) , 

BKNAM CHARACTER(30} , 

BKCON CHARACTER(30) , 

BKADR CHARACTER (40) , 

BKCTY CHARACTER ( 25 ) , 
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BXST 

BKZIP 

BKPKO 

CKGNUM 

SAVNUM 

TRINAM 

TRIADR 

TRICTY 

TRIST 

TRIZIP 

TR2NAM 

TR2ADR 

TRZCTY 

TR2ST 

TR2ZIP 

SGI 

S62 

APPDT 

MAIL 

FINFO 

EINFO 

STAT 

ACCID 

ACCGID 

LDT 

IiAMT 

LSRC 

GFEE 

GCST 

ACCAID 

AFBE 

CHAMl 

CNUMl 

CNAM2 

CNUM2 

CNAM3 
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CHARACTER (2), 
CHARACTER (10) , 
CHARACTER(20) , 
CHARACTER (20) , 
CHARACTER (20) , 
CHARACTER (30) , 
CHARACTER (40) , 
CHARACTER (25) , 
CHARACTER (2) , 
CHARACTER (10) , 
CHARACTER (30) , 
CHARACTER (40) ; 
CHARACTER (25) , 
CHARACTER (2) , 
CHARACTER (10) , 
CHARACTER (1) , 
CHARACTER (1) , 
DATETIME YEAR TO 
CHARACTER (1) , 
CHARACTER (1) , 
CHARACTER (1), 
CHARACTER (20) , 
INTEGER, 
INTEGER. 
DATE, 

DECIM2Ui(14,2) « 
CHAR(25) , 
DECIMAL (8, 4), 
CHAR(25) , 
INTEGER, 
DECIMAL (B ,4) , 
CHAR{35). 
CHAR(16) , 
'CHAR(35), 
CHAR(16) , 
CHAR(35) , 



SECOND, 



account assigned or null } 
guarantor account } 
limit date ) 
limit amount } 
limit source } 
guarantor fee ) 
guarantor customer id } 
association } 
association fee ) 
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CNUM3 CHAR(16), 

SRC CHAR (25} NOT NULL, { source 
SNTDTTM DATBTZMS YEAR TO SECOND, 
RSFDTTM DATETIMB YEAR TO SECOND, 
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PRIMARY KEY (ID) 
) lock mode row; 

CREATE TABLE N30TACC 



Table 18: NET30/Accounts 



ID INTEGER NOT NULL, 

TYP CHAR(l) NOT NULL, 

CDINDID INTEGER NOT NULL, 
TAXID CHAR (14), 
CRTUSRID CHAR (IS) NOT NULL, 
CRTDTTM DATBTIME 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (15) NOT NULL, 
CHGUSRID CHAR (15) NOT NULL, 
CH6DTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 
-CHGCLNT CHAR (15) NOT NULL, 



{ account id 

{ account type 

{ Industry code 

{ federal tax id c 

{ create user id 

{ create datetime 

{ create server 

{ create client 

{ change by user 

{ change datetime 

{ change server 

{ cheuige client 



vat } 



PRIMARY KEY (ID) CONSTRAINT N30CACCPK, 

CHECK (TYP IN ( 'A» , 'C , 'F» , 'G' , ' I ' , 'M' ) ) CONSTRAINT N30CACC1 
) LOCK MODE ROW; 



CREATE TABLE N30TACCNAM 



Table 19: NET30/Account Names 



ID INTEGER NOT NULL, 

ACCID INTEGER NOT NULL, 

PRI CHAR(l) NOT NULL, 

NAM CHAR (100) NOT NULL, 



{ name id 
{ account id 
{ Y/N, N = DBA 
( name 



-41- 



wo 01/058242 



PCTAJSOl/04515 



CNAM CHAR(IOO) 

DEFAULT "NOT DONE" 

NOT NULL, {compress name ) 

TODO: constraint to make sure there is one primary and zero or more non-primary. 
PRIMARY KEY (ID) CONSTRAINT N30CACCNAMPK, 

FOREIGN KEY (ACCID) REFERENCES N3 0TACC (ID) CONSTRAINT N3 OACCNAMPKl , 
CHECK (PRI IN CY', »N»)) CONSTRAINT N30ACCNAM1 
) LOCK MODE ROW; 

CREATE INDEX N30IACCNAM1 ON N30TACCNAM (NAM, ACCID) ; 
CREATE INDEX N30IACCNAM2 ON N30TACCNAM (CNAM) ; 

Table 20: NET30/Account Contacts 

CREATE TABLE N30TACCC0N 



ID 


INTEGER NOT NULL, 


{ contact id 


ACCID 


INTEGER NOT NULL, 


{ account id 


CDCONID 


INTEGER NOT NULL, 


{ contact type 


LNM 


CHAR(25) , 


{ last name 


FNM 


CKAR(25) , 


{ first name 


MNN 


CHAR(2S) , 


{ middle name 


JOB 


CHAR(40) , 


( job title 


DPT 


CHAR(40) , 


{ department 


URL 


CHAR(IOO) , 


{ www url 


EML 


CHAR(80) , 


{ email address 


PHN 


CHAR(20) , 


{ voice phone 


PAX 


CHAR(20) , 


{ fax number 


MBL 


CHAR(20) , 


{ mobile phone 


PGR 


CHAR(20) , 


{ pager number 


NTS 


CHAR(IOOO) , 


{ notes 


ATTN 


CHAR(40) , 


{ attn: line 


ADDRl 


CHAR(40) , 


{ address 1 


ADDR2 


CHAR(40) , 


{ address 2 


ADDR3 


CHAR(40} , 


{ address 3 


CTY 


CHAR(40} , 


{ city 


STCODID 


CHAR(2), 


{ state code 
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ZIP CHAR (14), 

CYCODID CHAR (2), 
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{ zip } 
{ country code } 



-- TODO: Need PK constraints on codes. 
PRIMARY KEY (ID) CONSTRAINT N30CACCCONPK, 

FOREIGN KEY (ACCID) REFERENCES N30TACC (ID) CONSTRAINT NSOCACCCONFKl 
) LOCK MODE ROW; 

CREATE UNIQUE INDEX N30IACCCON ON N30TACCCON (ACCID, CDCONID) ; 



Table 21: NET30/Account Balances 



CREATE TABLE N30TACCBAL 



ID 


INT8 NOT NULL, 




{ unique id } 


YR 


INTEGER NOT NZ7LL, 




{ year, 2000. . . } 


PD 


INTEGER NOT NULL| 




{ period } 


ACCID 


INTEGER NOT NULL, 




{ account id } 


BBL 


MONEY (14,2) NOT 


NULL, 


{ current pd beg balance ) 


EBL 


MONEY (14,2) NOT 


NULL, 


{ current /ending balance ) 


CBBL 


MONEY (14,2) NOT 


NULL, 


{ pd beg auth balance } 


CEBL 


MONEY (14,2) NOT 


NULL, 


{ current/ ending auth bal } 


PRIMARY 


KEY (ID) , 






UNIQUE 


(YR, PD, ACCID), 







FOREIGN KEY (ACCID) REFERENCES N30TACC (ID) CONSTRAINT N3 OCACCBALFKl 
} LOCK MODE ROW; 



Table 22: N£T30/Account Audit History 



CRBA.TE TABLE N30TACCAUD 



ID INT8 NOT NULL, 

ACCID INTEGER NOT NULL, 

ATTR CHAR (20) NOT NULL, 

OVAL CHAR (20) NOT NULL, 

NVAL CHAR(20) NOT NULL, 



{ id 

{ account number 
( attribute 
{ old value 
{ new value 



CRTUSRID CHARdS) NOT NULL, 
CRTDTTM DATETIME 



{ create user id } 
{ create datetime } 
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YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (IS) NOT NULL, 
CHGUSRID CHAR (15) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 
CHGChNT CHAR (IS) NOT NULL, 
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{ create server } 

{ create client ) 

{ change by user ) 

{ change date time } 

{ change server } 

{ change client ) 



PRIMARY KEY (ID) CONSTRAINT N30CACCAUDPK, 

FOREIGN KEY (ACCID) REFERENCES N3 0TACC(ID) CONSTRAINT N30CACCADDFK1' 
) LOCK MODE ROW; 

Table 23: NEXSO/Merchant Account Master 

CREATE TABLE N30TACCM 
( 

ID INTEGER NOT NULL, { account id ) 

STDT DATE, 



PRIMARY KEY (ID) , 

FOREIGN KEY (ID) REFERENCES N30TACC(ID) 
) LOCK MODE ROW; 



CREATE TABLE N30TKTWRK 



Table 24: Networks 



ID INTEGER NOT NULL, 

NAM CHAR (20) NOT NULL, 



{ unique id 
{ network name 



CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHARdS) NOT NULL, 
CRTCLNT CHAR(15) NOT NULL, 
CHGUSRID CHARdS) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 



( create user id 

{ create datetime 

{ create server 

{ create client 

{ change by user 

( change datetime 



-44- 



wo 01/058242 

CHGSRVR CHAR (15} NOT mLL, 
CHGCLNT CHAR (IS) NOT NULL, 



{ change server ) 
{ change client } 
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PRIMARY KEY (ID) CONSTRAINT N30CNTWRKPK 
) LOCK MODE ROW; 



CREATE TABLE N30TACCMTRM 



Table 25: Merchant Terminals 



ID INTEGER NOT NULL, 

ACCMID INTEGER NOT NULL, 
NTWRKID INTEGER NOT NULL, 
TRMADDR CHAR (20) NOT NULL, 
ACT CHARd) NOT NULL, 



{ unique id 

{ merchant id 

{ network id 

{ terminal address 



CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATBTIME 

YEAR TO SECOND NOT MULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (15) NOT NULL, 
CHGUSRID CHARdS) NOT NULL, 
CHGDTTM DATETIMB 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 
CHGCLNT CHAR (IS) NOT NULL, 



{ create user id 

{ create date time 

{ create server 

{ create client 

{ change by user 

{ change date time 

( change server 

{ change client 



PRIMARY KEY (ID) CONSTRAINT N30CACCMTRMPK, 
UNIQUE (NTWRKID, TRMADDR) CONSTRAINT N3 0CACCMTRM2, 
FOREIGN KEY (ACCMID) REFERENCES N30TACCM (ID) , 
FOREIGN KEY (NTWRKID) REFERENCES N30TNTWRK (ID) 
) LOCK MODE ROW; 

Table 26: N£T30/Guarnnror Account Master 

CREATE TABLE N30TACCG 
( 

ID INTEGER NOT NULL, { account id ) 

MXN MONEY(14,2} NOT NULL, 
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PRIMARY KEY (ID) , 

FOREIGN KBY (ID) REFERENCES N30TACC(ID) 
) LOCK MODE ROW; 

Table 27: NET30/AssociatiOD Account Master 

GREATS TABIiE N30TACCA 

( 

ID INTEGER NOT NULL, { account Id } 

SRC CHAR (20) NOT NULL, 



PRIMARY KEY (ID) , 

FOREIGN KBY (ID) REFERENCES N30TACC(ID) 
} LOCK MODE ROW; 

Table 28: N£T30/Issuer Account Master 

CREATE TABLE N30TACCI 
( 

ID INTEGER NOT NULL, { account Id } 

ATR CHAR (10) NOT NULL. 



PRIMARY KEY (ID) , 

FOREIGN KEY (ID) REFERENCES N30TACC(ID) 
} LOCK MODE ROW; 



Table 29: NET30/Card Holder Account Master 



CREATE TABLE N30TACCCH 



ID INTEGER NOT NULL, 

GACCID INTEGER NOT NULL, 

GCID CHAR (20), 

GFEE DECIMAL (6, 4} NOT NULL, 

CDCHSID INTEGER NOT NULL, 

AACCID INTEGER, 

AFEE DECIMAL (6, 4) , 

LAMT MONEY (14, 2), 

LDT DATE, 



{ account id 

{ guarantor accid 

{ guarantor cust id 

{ guarantor fee % 
{ credit status 
{ as see acct id 

{ assoG fee % 
{ limit amt 
( limit date 
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LSRC CHAR(20), { limit source ) 

SRC CHAR (20), { cr line source } 



PRIMARY KEY (ID) CONSTRAINT N30CACCCHPK, 

FOREIGN KEY (ID) REFERENCES N30TACC(ID) CONSTRAINT N3 0CACCCHFK1, 
FOREIGN KEY (GACCID) REFERENCES N30TACC(ID) CONSTRAINT N3 0CACCCHFK2 , 
FOREIGN KEY (AACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCCHFK3 
) LOCK MODE ROW; 

--CREATE UNIQUE INDEX N30IACCCH1 ON N30TACCCH (GACCID, GCID) ; 

Table 30: N£T30/Card Holder Cards 

CREATE TABLE N30TACCCHC 
( 

lO INTEGER NOT NULL, { card id} 

CNUM INT8 NOT NOLL, { card niunber } 

ACCID INTEGER NOT NULL, { account id } 

NM CHAR (50) NOT NULL, { name on card } 

IDT DATE NOT NULL, { issue date ) 

EDT DATE NOT NULL, { expire date ) 

CDCHCSID INTEGER NOT NULL, { card status } 

PIN CHAR (15), { pin code or null ) 

ACCCHCBID INTEGER, { card batch or null } 



PRIMARY KEY (ID) CONSTRAINT N3 OCACCCHCPK, 

FOREIGN KEY (ACCID) REFERENCES N30TACC(ID) CONSTRAINT N3 OCACCCHCPKl , 
UNIQUE (CNUM) CONSTRAINT N30CACCCHC3 
) LOCK MODE ROW; 

CREATE UNIQUE INDEX N30IACCCHC1 ON N30TACCCHC (ACCID, ID) ; 

Table 31: NET30/Card Holder Credit Limit History 

CREATB TABLE N30TACCCHL 
( 

ID INT8 NOT MULL, {unique id } 

ACCID INTEGER NOT NULL, { account id } 

LAMT MONEY (14, 2), { limit amt } 

LDT DATE, { limit date } 

LSRC CHAR(20), { limit source } 
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CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIMB 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (15) NOT NULL, 
CHGUSRID CHAR (15) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 
CHGCLNT CHAR (15) NOT NULL, 
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{ create user id 

{ create datetime 

{ create server 

{ create client 

{ change by user 

{ change datetime 

{ change server 

{ change client 



PRIMARY KEY (ID) CONSTRAINT N30CACCCHLPK, 

FOREIGN KEY (ACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCCHLFK1 
) LOCK MODE ROW; 

Table 32: NETSO/Card Holder Authorization Attempts 
(Logs failed or successful attempt to authorize against a card. Only APPROVED authorizations make it into the transaction table) 

CREATE TABLE N30TACCCHA 



ID 


INT8 NOT NULL, 


{ AUTH id 


} 


ACCCHID 


INTEGER, 


{ card holder 


) 


ACCCHCID 


INTEGER, 


{ card 


} 


CNUM 


CHAR(16) , 


{ card number entered 


) 


ACCMID 


INTEGER NOT NULL, 


{ merchant -- maybe 


invalid, 


DOC 


CHAR(20) , 


{ po, inv, etc 


} 


DTTM 


DATETIME 


{ actual date /time 


} 




YEAR TO SECOND NOT NULL, 






CDRSPID 


INTEGER NOT NULL, 


{ auth response } 




ACCTRNID 


INT8 NOT NULL, 


{auth tran id } 




CRBAL 


MONEY (14, 2) , 


(avail cr } 




NAM 


CHAR(35) , 


{ name on card } 




EXP 


CHAR(IO) , 


{ esqpiration given } 





CRTUSRID 
CRTDTTM 



CRTSRVR 



CHAR (15) NOT NULL, 
DATETIMB 

YEAR TO SECOND NOT NULL, 
CHAR (15) NOT NULL, 



{ create user id } 
{ create datetime ] 

{ create server } 
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CRTCLNT 

CHGUSRID 
CHGDTTM 

CHGSRVR 
CHGCIiNT 
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CHAR (IS) NOT NULL, 
CHAR (15) NOT NULL, 
DATETIME 

YEAR TO SECOND NOT NULL, 
CHAR (15) NOT NULL, 
CHAR (15) NOT NULL, 



{ create client ) 

{ change by user } 

{ change datetime } 

{ change server } 

( change client } 



PRIMARY KEY (ID) CONSTRAINT N30CACCCHAPK 
) LOCK MODE ROW; 



Table 33: NET30/Account Transaction Master Table 
(Describes a single authorization, invoice receipt, payment receipt, merchant check, promotional; balance adjustment, etc.) 

CREATE TABLE N30TACCTRN 



ID INT8 NOT NULL, 

CDTRNID INTEGER NOT NULL, 

YR INTEGER NOT NULL, 

PD INTEGER NOT NULL, 

6RF INT8 NOT NX7LL, 

ACCCHID INTEGER NOT NULL, 

ACCCHCID INTEGER NOT NULL, 

ACCMXD INTEGER NOT NULL, 

AMT MONEY(14,2) NOT NULL, 

DOC CHAR (20), 

DTTM DATETIME 

YEAR TO SECOND NOT NULL, 

CDPMTID INTEGER NOT NULL, 

ACCX3SLID INT8, 



tran id } 

transaction type } 

year } 

period } 

group id 

card holder 

card 

merchant 

amotint 

po , inv , chk# , etc 
actual date/time 

terms 

sales batch id 



CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (15) NOT NULL, 
CHGUSRID CHARdS) NOT NULL, 
CHGDTTO DATETIME 

YEAR TO SECOND NOT NULL, 



{ create user id } 
{ create datetime } 

{ create server ) 

{ create client } 

I change by user ) 

{ change datetime } 
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CHGSRVR CHAR (15) NOT NULL, 
CHGCIiNT CHAR (15) NOT NULL, 



{ change server } 
{ change client ) 
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PRIMARY KEY (ID) CONSTRAINT N30CACCTRNPK 
) LOCK MODE ROW; 

CREATE INDEX N30IACCTRN1 ON N30TACCTRN (CRTDTTM, CDTRNID) ; 



Table 34: N£T30/Account Transaction Detail 



CREATE TABLE N30TACCTRND 



ID INT8 NOT NULL, 

YR INTEGER NOT NULL, 

PD INTEGER NOT NULL, 

ACCID INTEGER NOT NULL, 
ACCTRNID INT8 NOT NULL, 
CDTRNDID INTEGER NOT NULL, 
DTTM DATETIMB 

YEAR TO SECOND NOT NULL, 
AMT MONEY (14,2) NOT NULL, { tran amoiint 

EBL MONEY (14,2) NOT NULL, { new bal amount 

CEBL MONEY (14,2) NOT NULL, { new cr bal amt 
STMT INT8 NOT NULL, { statement id 



{ tran id 
{ year 
{ period 
{ account id 
{paren tran 
{tran type 
{ tran timestamp 



CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATBTIME 

YETUl TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (15) NOT NULL, 
CHGUSRID CHAR (15) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 
CHGCLNT CHAR (IS) NOT NULL, 



{ create user id 

{ create date time 

{ create server 

{ create client 

{ change by user 

{ change datetime 

{ change server 

{ change client 



PRIMARY KEY (ID) CONSTRAINT N30CACCTRNDPK. 

FOREIGN KEY (ACCTRNID) REFERENCES N30TACCTRN (ID) CONSTRAINT N30CACCTRNDFK1 
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) LOCK MODE ROW; 
CREATE TABLE N3 0TACCS 
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Table 35: 



ID INT8 NOT NULL, 

ACCSBID INTEGER NOT NULL, 

FRDT DATE NOT NULL, 

THDT DATE NOT NULL, 

ACCID INTEGER NOT NULL, 

BBL MONEY (14, 2) NOT NULL, 

CBB MONEY (14, 2) NOT NULL, 

EBL MONEY (14, 2) NOT NULL, 

CEBL MONEY (14, 2) NOT NULL, 

LAMT MONEY (14, 2), 

AVL M0NKY(14,2), 



{ stmt id 

{ stmt batch id 

{ from date 

{ through date 

{ account id 

{ beg bal 

{ beg cr bal 

( end bal 

{ end cr bal 

{ cr limit if ch 

( available cr bal 



CRTDSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIMB 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR(15) NOT NULL, 

CRTCLNT CHAR (15) NOT NULL, 

CHGUSRID CHAR (15) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT MULL, 
CH6SRVR CHAR (15) NOT NULL, 

CH6CLNT CHAR (15) NOT NULL, 



{ create user id 

{ create datetime 

{ create server 

{ create client 

{ change by user 

{ change datetime 

{ change sexver 

{ change client 



PRIMARY KEY (ID) CONSTRAINT N30CACCSPK, 

FOREIGN KEY (ACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCSPK1 
) LOCK MODE ROW; 

VIEW: NET30/Card Holder Fees 

CREATE VIEW N30VACCCH1 
AS 

SELECT ID, GACCID, GFEE, AACCID, AFEB 
FROM N30TACCCH; 
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VIEW: N£T30/rraD5actioi] Detail Statement 

create view n30vacctmdl as 
select 

det.yr, det.pd, det.accld, det.acctmld, det.id, det.dttm, 
^et.amt as damt, det.ebl, det.cebl, ddsc.desc as ddesc, det.stmt, 
ddsc . bad j , ddsc . cad j , 

chnam.nam as chnam, crd.cnumi memam.nam as tnernam, trn.amt as tamt, trn.doc, 
tm.dttm as tdttm, tdsc.desc as tdesc 
from 

nSOtacctmd as detj 
n30tcdtrnd as ddsc, 
n30tacctm as trn, 
n30tcdtm as tdsCi 
outer n30taccnam as chnam, 
outer n30taccnaTn as memam, 
outer n30taccchc as crd 
where 

det.cdtrndld = ddsc. id 
and det.acctmid » tm.id 
and tm.cdtrnid = tdsc.id 

Eind tm.accchid = chnam. accid and chnara.pri = 'Y' 
and tm.accraid = memam. accid and memam. pri « 'Y' 
and tm.accchcid = crd. id 



Table 36: Guarantor Sales Batch 



C31EATB TABLE N30TACC6SL 



ID Iin:8 NOT NULIi, 

ACCGID IKTBGER NOT NULL, 

SIZ INTEGER NOT NULL, 

CRB CHAR(l) 

CHECK (CRB IN ('Y», 'N')), 
TXDTTM DATETIME 

YEAR TO SECOND, 
CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIME 



{ UNIQUE ID } 
{ GUARANTOR ACCOUNT ID } 



{ DETAIL ITEM COUNT 
{ credit/debit batch 

{ TRANSMIT DATETIME 

( create user id } 
{ create datetime } 



) 
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YEAR TO SECOND NOT NULL, 
Ca^TSRVR CHAR (15) NOT KDZiIi, 

CRTCLNT CHAR (15) NOT NULL, 

CHGUSRID CHAR (15) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 

CHGCLNT CHAR (15) NOT NULL. 



{ create server } 

( create client } 

{ change by user } 

{ change datetime } 

{ change server ) 

{ change client ) 



PRIMARY KEY (ID) CONSTRAINT N3 OCACCGSLPK, 

FOREIGN KEY{ACCGID) REFERENCES N30TACCG(ID) CONSTRAINT N3 OCACCGSLPKl 

); 

Table 37: Card Batch Statuses 

CREATE TABLE N30TCDCHCB 
( 

ID INTEGER NOT NULL, 

DESC CHAR(20) NOT NX7LL, 



PRIMARY KEY (ID) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

CREATE TABLE N30TACCCHCB 



Table 38: Card Printing^ra bossing Batches 



ID INTEGER NOT NULL, 

CDCHCBID INTEGER NOT NULL, 
CNT INTEGER NOT NULL, 

SELDTTM DATETIME 

YEAR TO SECOND, 
RCVDTTM DATETIME 

YEAR TO SECOND, 
CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (IS) NOT NULL, 



{ unique id } 
{ batch status } 
{ number of cards } 
{ select timestanrp } 

{ receiv timestamp } 

{ create user id } 
{ create datetime } 

{ create server } 
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( create client } 
{ change by user } 
{ change datetime } 

{ change server ) 
{ change client } 

PRIMARY KEY (ID) CONSTRAINT N3 OCACCCHCBPK 

) LOCK MODE ROW; 

Table 39: Card Holder Application 

CREATE TABLE N30TAPPCH 
( 

ID INTEGER NOT NULL, 



FNUU4 CHARACTEROO) NOT NULL, 

LNAM CHARACTEROO) NOT NTEiL, 

MNAM CHARACTEROO), 

CPNAM CHARACTER (40) NOT NULL, 

ADRl CHARACTEROO) NOT NULL, 

ADR2 CHARACTEROO), 

ADR3 CHARACTEROO) , 

CTY CHARACTER (25) NOT NULL, 

ST CHARACTER (2) NOT NULL, 

ZIP CHARACTEROO) NOT NULL, 

CTRY CHARACTER ( 2 ) , 

PHO CHARACTER (20) NOT NULL, 

FAX CHARACTER ( 20 ) , 

EMAIL CHARACTEROO), 

BADRl CHARACTEROO) NOT NULL, 

BADR2 CHARACTEROO), 

BADR3 CHARACTER (30), 

BCTY CHARACTER (25) NOT NULL, 

BST CHARACTER (2) NOT NULL, 

BZIP CHARACTEROO) NOT NULL, 

BCTRY CHARACTER { 2 ) , 



CRTCLNT CHAR (15) NOT NULL, 

CHGUSRID CHAR (15) NOT NULL, 
CHQDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 

CHGCLNT CHAR (15) NOT NULL, 
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OFF 

OFFT 

CON 

CONT 

CDINDID 

LOGS 

DUNS 

DBA 

PCPY 

TAXID 

ASLS 

EDATE 

EMPS 

CHAMl 

CNUMl 

CNAM2 

CNUM2 

CNAM3 

CNUM3 

BKNAM 

BKCON 

BKADR 

CKGHUM 

BKCTY 

BKST 

BKZZP 

BKPHO 

BKCTRY 

SAVNUM 

BINAM 

BIPHN 

BlADRl 

B1ADR2 

B1ADR3 

BICTY 

BIST 
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CHARACTER (3 0 
CHARACTER (3 0 
CHARACTER (30 
CHARACTER (30 
INTEGER NOT NULL, 
INTEGER NOT NULL, 
CHARACTER (20 
CHARACTER (30 
CHARACTER (30 
CHARACTER (20 
INTEGER NOT NULL, 
CHARACTER (20 



INTEGER NOT NULL, 



CHARACTER (3 5 
CHARACTER (16 
CHARACTER (3 5 
CHARACTER (16 
CHARACTER (35 
CHARACTER (16 
CHARACTER (30 
CHARACTER (30: 
CHARACTER (40 
CHARACTER (20 
CHARACTER (25 
CHARACTER (2) 
CHARACTER (10 
CHARACTER (20 
CHARACTER (2) 
CH2UIACTER(20: 
CHARACTER (3 o: 
CHARACTER (20 
CHARACTER (30 
CHARACTER (30 
CHARACTER (30 
CHARACTER (25 
CHARACTER (2) , 



NOT NULL, 
NOT NULL, 
NOT NULL. 
NOT NULL, 



NOT NULL, 



HOT NULL, 
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BIZIP CHARACTER (10) , 

BICTRY CHARACTER (2) , 

B2NAM CHARACTER (30), 

B2 PHN CHARACTER ( 20 ) . 

B2 ADRl CHARACTER (30), 

B2 ADR2 CHARACTER (30), 

B2ADR3 CHARACTER (30) , 

B2CTY CHARACTER (25) , 

B2ST CHARACTER (2) , 

B22IP' CHARACTER (10) , 

B2CTRY CHARACTER(2) , 

SIGl CHARACTER (1) NOT NULL CHECK (SIGl IN ('Y', 'N'J), 

APPDT DATETIME YEAR TO SECOND, 

CDAST INTEGER NOT NULL, 

ACCCHID INTEGER, { account assigned or null ) 

ACCGID INTEGER, { guarantor account ) 

*LDT DATE, { limit date ) 

LAMT DECIMAL ( 14 , 2 ) , { limit amount } 

LSRC CHARACTER (25) , { limit source } 

GFBE DECIMAL (8, 4), { guarantor fee } 

GCST CHARACTER ( 25 ) , { guarantor customer id } 

ACCAID INTEGER, { association } 

AFEB DECIMAL (8 ,4), { association fee } 

SRC CHARACTER (25) NOT NULL, { source } 

SNTDTTM DATETIME YEAR TO SECOND, 

RSPDTTM DATETIME YEAR TO SECOND, 

CRTUSRID CHAR (15) NOT NULL, { create user id } 

CRTDTTM DATETIME { create datetime } 

YEAR TO SECOND NOT NULL, 

CRTSRVR CHARACTER (15) NOT NULL, { create server ) 

CRTCLNT CHARACTER (15) NOT NULL, { create client } 

CHGDSRID CHARACTER (15) NOT NULL, { change by user } 

CHGDTTM DATETIME { change datetime ) 

YEAR TO SECOND NOT NULL, 

CHGSRVR CHARACTERdS) NOT NULL, { change server ) 

CHGCLNT CHARACTERdS) NOT NULL, { change client } 
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PRIMARY KEY (ID) 
} lock mode row; 

Table 40: Merchant Agreement 

CREATE TABLE N30TAPPM 
( 

ID INTEGER NOT NULL, 



CPNAM CHARACTER (40} NOT NULL, 

ADRl CHARACTEROO) NOT NULL, 

ADR2 CHARACTEROO) , 

At}R3 CHARACTEROO) , 

CTY CHARACTER(25) NOT NULL, 

ST CHARACTER (2) NOT NULL, 

ZIP CHARACTER (10) NOT NULL, 

CTRY CHARACTER (2) , 

PHO CHARACTER(20) NOT NULL, 

FAX CHARACTER (20) , 

MADRl CHARACTER (30), 

MADR2 CHARACTER (30), 

MADR3 CHARACTER (30), 

MCTY CHARACTER (25), 

MST CHARACTER (2) , 

MZIP CHARACTER(IO) , 

MCTRY CHARACTER ( 2 ) , 

TAXID CHARACTER (20), 

CDINDID INTEGER NOT NULL, 

PPNAM CHARACTER (30) NOT NULL, 

PLNAM CHARACTER (30) NOT NULL, 

PMNAM CHARACTER (30), 

PADRl CHARACTER (30), 

PADR2 CHARACTEROO), 

PADR3 CHARACTER (30), 

PCTY CHARACTER(25) , 

PST CHARACTER (2) , 

PZIP CHARACTER ( 10 ) , 
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PCTRY 

PPHO 

PEMAIL 

AFNAM 

ALNAM 

AADRl 

AADR2 

AADR3 

ACTY 

AST 

AZIP 

ACTRY 

APHO 

SIGl 

SRC 

APPDT 

CDAST 

ACCMID 

CRTUSRID 

CRTDTTM 

CRTSRVR 
CRTCLMT 
CHGUSRID 
CHGDTTM 

CHGSRVR 
CHGCIiNT 
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CHARACTER(2) , 
CHARACTER (20) , 
CHARACTER (30) , 
CHARACTER (30) , 
CHARACTER (30) , 
CHARACTER(30) , 
CHARACTER (30) , 
CHARACTER (30) , 
CHARACTER (25) , 
CHARACTER (2) , 
CHARACTER (10) , 
CHARACTER(2) , 
CHARACTER (20) , 

CHARACTBR(l) NOT NULL CHECK (SIGl IN ('Y', 'N')), 
CHARACTER (25) NOT NULL, { source ) 
DATETIMB YEAR TO SECOND, 
INTEGER NOT NDLL, 

INTEGER, { account assigned or null } 

CHAR (15) NOT NULL/ { create user id } 

DATETIME { create datetime } 

YEAR TO SECOND NOT NULL, 

CHAR (15) NOT NULL, { create server } 

CHARdS) NOT NULL, { create client } 

CHAR (15) NOT NULL, { change by user ) 

DATETIME { change datetime } 

YEAR TO SECOND NOT NULL, 

CHAR (as) NOT NULL, { change server } 

CHARdS) NOT NULL, { change client } 



60 



65 



PRIMARY KEY (ID) 



} lock mode row; 



CREATE TABLE N30TCDCHLRS 



Table 41: NETSO/Card Holder Line Request Statuses 



70 



ID INTEGER NOT NULL, 
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DESC CHAR (20) NOT NULL. 



PRIMARY KEY (ID) , 
UNIQUE (DESC) 
) LOCK MODE ROW; 

CREATE TABLE N30TACCCHLR 



Table 42: N£T30/Card Holder Lioe Requests 



ID INT8 NOT NULL, 

ACCGID INTEGER NOT NULL, 
ACCCHID INTEGER NOT NULL, 
RQAMT DECIMAL (14, 2) NOT NULL, 
SNTDTTM DATETIME YEAR TO SECOND, 
RSPDTTM DATETIME YEAR TO SECOND, 
RSPAMT DECIMAL (14, 2) , 
CDCHLRSID INTEGER, 



{ request Id} 

{ guarantor } 

{ card holder id } 

{ requested amount, possibly zero } 

{ tiroes tamp sent to guarantor } 

{ timestamp received from guarantor ) 

{ amount approved } 

{ response code from guarantor - our own code } 



PRIMARY KEY (ID) CONSTRAINT N30CACCCHLRPK, 

FOREIGN KEY (ACCGID) REFERENCES N30TACCG(ID) CONSTRAINT N3 0CACCCHLRPK1, 
FOREIGN KEY (ACCCHID) REFERENCES N30TACCCH(ID) CONSTRAINT N3 0CACCCHLRFK2 , 
FOREIGN KEY (CDCHLRSID) REFERENCES N30TCDCHLRS (ID) CONSTRAINT N30CACCCHLRFK3 
) LOCK MODE ROW,- 

Table 43: References 

CREATE TABLE N30TACCREF 
( 

ID INTEGER NOT NULL, 
ACCID INTEGER NOT NULL, 



LOCS INTEGER NOT NULL, 

DUNS CHARACTER (20) , 

PCPY CHARACTER (30), 

ASLS INTEGER NOT NULL, 

EDATE CHARACTER (20) NOT NULL, 

BMPS INTEGER NOT NULL, 

BKNAM CHARACTER (30), 

BKCON CHARACTER (30), 
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BKADR 

CKGNUM 

BKCTY 

BKST 

BKZIP 

BKPHO 

BKCTRY 

SAVNX3M 

BINAM 

BIPHH 

B1ADR2 

B1ADR3 

BICTY 

BIST 

BIZIP 

BICTRY 

B2NAM 

B2PHN 

B2ADR1 

B2ADR2 

B2CTY 

B2ST 

B2ZIP 

B2CTRY 

CRTUSRID 

CRTDTTM 

CRTSRVR 
CRTCLNT 
CHGUSRXD 
CHGDTTM 

CHGSRVR 
CHGCLNT 
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CHARACTER (40) . 
CHARACTER (20) , 
CHARACTER (25) , 
CHARACTER (2) , 
CHARACTER (10) , 
CHARACTER (20) , 
CHARACTER (2 ) , 
CHARACTER (20) , 
CHARACTEROO) , 
CHARACTER(20) , 
CHARACTEROO) , 
CHARACTEROO) , 
CKARACTEROO) , 
CHARACTER (25) , 
CHARACTER (2) , 
CHARACTER (10) , 
CHARACTER (2) , 
CHARACTEROO) , 
CHARACTER (20) , 
CHARACTEROO), 
CHARACTEROO) . 
CHARACTEROO) , 
CHARACTER(25) , 
CHARACTER (2) , 
CHARACTER (10) , 
CKARACTER(2) , 

CHAR (15) NOT NULL, { create user id } 

DATBTIME { create datetime } 
YEAR TO SECOND NOT NULL, 

CHARACTER (15) NOT NOLL, { create server } 
CHARACTBRdS) NOT NDLL, { create client ) 
CHARACTER (IS) NOT NULL, { change by user } 
DATETIME { change datetime } 
YEAR TO SECOND NOT NULL, 

CHARACTER (15) NOT NULL, { change server ) 
CHARACTERdS) NOT NULL, { change client ) 



-60- 



wo 01/058242 



PCTAJSOl/04515 



PRIMARY KEY (ID) CONSTRAINT N3 OCACCREFPK, 

FOREIGN KEY (ACCID) REFERENCES N30TACC(ID) CONSTRAINT N30CACCREFFK1 
) lock mode row; 

Table 44: 



CREATE TABLE N3 0TACCSB 
( 

ID INTEGER NOT NULL, 

PRTDT DATE, 

THDT DATE NOT NULL, ( through date 

CRTDSRID CHJUldS) NOT NULL, { create user id } 

CRTDTTM DATBTIME { create datetime } 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHARACTER (15) NOT NULL, { create server } 
CRTCLNT CHARACTER (15) NOT NULL, { create client } 
CHGUSRID CHARACTER (15) NOT NULL, { change by user } 
CHGDTTM DATETIME { change datetime } 

YEAR TO SECOND NOT NULL, 
CHGSRVR ' CHARACTER (15) NOT NULL, '{ change server } 
CHGCLNT CHARACTER (15) NOT NULL, { change client ) 



PRIMARY KEY (ID) CONSTRAINT N30CACCSBPK 
) lock mode row; 

VI£W: N£T30/Card Holder tine Requests 
CREATE VIEW N30VACCCHLR1 (ID, ACCCHID) 
AS 

SELECT MAX (ID), ACCCHID 
FROM 

N30TACCCHLR 
GROUP BY 
ACCCHID; 

Expand SYSTID.NM 

ALTER TABLE SYSTID MODIFY NM CHAR (20) ; 

Table 45: Sales Status 
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CREATE TABLE N30TCDSLSST 

5 

ID INTEGER DEPAU?jT 10 NOT NULL, 

DESC CHAROO) not NULL, 

10 

PRIMARY KEY <1D) CONSTRAINT N30CCDSLSSTPK, 
UNIQUE (DESC) CONSTRAINT N30CCDSLSST1 

15 

) LOCK MODE ROW; 

INSERT INTO SYSTID (NM, LSTID) VALUES ( "NSOTCDSLSST" , 30); 

20 



INSERT 


INTO N30TCDSLSST 


(ID, 


DESC) 


VALUES 


(10, 


"New Lead" } ; 


INSERT 


INTO N30TCDSLSST 


(ID, 


DESC) 


VALUES 


(20, 


"Waiting on Agreement"); 


INSERT 


INTO N30TCDSLSST 


(ID, 


DESC) 


VALUES 


(30, 


"Mail Agreement"); 


INSERT 


INTO N30TCDSLSST 


(ID. 


DESC) 


VALUES 


(40, 


"See At Show") ; 


INSERT 


INTO N30TCDSLSST 


(ID, 


DESC) 


VALUES 


(50, 


"Need decision maker")/ 


INSERT 


INTO N30TCDSLSST 


(ID, 


DESC) 


VALUES 


(60, 


"Not Interested"); 


INSERT 


INTO N30TCDSLSST 


(ID, 


DESC) 


VALUES 


(70, 


"No Answer") ; 


INSERT 


INTO N30TCDSLSST 


(ID, 


DESC) 


VALUES 


(80, 


"Other") ; 



Table 46: Agreement Status 

40 

CREATE TABLE N30TCDAGST 
( 

45 ID INTEGER DEFAULT 40 NOT NULL, 

DESC CHAROO) NOT NULL, 

50 

PRIMARY KEY (ID) CONSTRAINT N30CCDAGSTPK, 
UNIQUE (DESC) CONSTRAINT N30CCDAGST1 
55 ) LOCK MODE ROW; 

INSERT INTO SYSTID (NM, LSTID) VALUES {"N30TCDAGST" , 30); 

60 

INSERT INTO N30TCDAGST (ID, DESC) VALUES (10, "Paxed") ; 
INSERT INTO N30TCDAGST (ID, DESC) VALUES (20, "Mailed"); 
65 INSERT INTO N30TCDAGST (ID, DESC) VALUES (30, "Complete"); 
INSERT INTO N30TCDAGST (ID, DESC) VALUES (40, "Not Sent") ; 

70 Table 47: App Status Reason 
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CREATE TABLE N30TCDASTR 
{ 

ID INTEGER NOT NULL, 

DESC CHAR (30) NOT NULL, 

PRIMARY KEY (ID) CONSTRAINT N3 OCCDASTRPK, 
UNIQUE (DESC) CONSTRAINT N30CCDASTR1 
) LOCK MODE ROW; 

INSERT INTO SYSTID (NM, LSTID) VALUES ("N30TCDASTR« , 30); 

INSERT INTO N30TCDASTR (ID, DESC) VALUES (10, "Not interested"); 
INSERT INTO N30TCDASTR (ID, DESC) VALUES (20, "No such company"),- 
INSERT INTO N30TCDASTR (ID, DESC) VALUES (30, "Duplicate"); 

{ 

NEW Statuses FOR apps 

} 



INSERT 


INTO 


N30TCDAST 


(ID, 


DESC) 


VALUES 


(5, 


"Data quality waiting") ; 


INSBKT 


INTO 


N30TCDAST 


(ID, 


DESC) 


VALUES 


(6, 


"Sales waiting") ; 


INSERT 


INTO 


N30TCDAST 


(ID, 


DESC) 


VALUES 


(7, 


"In process") ; 


INSERT 


INTO 


N30TCDAST 


(ID, 


DESC) 


VALUES 


(8, 


"Suspended") ; 












NEW statuses FOR apps 


INSERT 


INTO 


N3 0TCDAST 


(ID, 


DESC) 


VALUES 


(5, 


"Data quality waiting") ; 


INSERT 


INTO 


N3 OTCDAST 


(ID, 


DESC) 


VALUES 


(6. 


"Sales waiting") ; 


INSERT 


INTO 


N30TCDAST 


(ID, 


DESC) 


VALUES 


(7. 


"In process") ; 


INSERT 


INTO 


N3 OTCDAST 


(ID, 


DESC) 


VALUES 


(8. 


"Suspended") ; 



Card Holder Changes 

ALTER TABLE N30TAPPCH ADD NTS TEXT; ( Comments } 

ALTER TABLE M30TAPPCH ADD CDSLSSTID INTEGER; { Sales Status ) 

ALTER TABLE N30TAPPCH ADD CONSTRAINT 

FOREIGN KEY (CDSLSSTID) REFERENCES N30TCDSLSST (ID) CONSTRAINT N3 OCAPPCHFKl ; 

ALTER TABLE N30TAPPCH ADD CDAGSTID INTEGER; { Agreement Status } 

ALTER TABLE N30TAPPCH ADD CONSTRAINT 
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FOREIGN KEY (CDAGSTID) REFERENCES NSOTCUAGST (ID) CONSTRMNT N30CAPPCHFK2 ; 



ALTER TABLE N30TAPPCH ADD CDASTRID INTEGER; { App Status Reason } 
ALTER TABLE N30TAPPCH ADD CONSTRAINT 

FOREIGN KEY (CDASTRID) REFERENCES N30TCDASTR (ID) CONSTRAINT N30CAPPCHFK3 ? 

ALTER TABLE N30TAPPCH ADD AGNUSRID INTEGER; { agent systusr.id working } 

ALTER TABLE N30TAPPCH ADD CONSTRAINT 

FOREIGN KEY (AGNUSRID) REFERENCES SYSTUSR(ID) CONSTRAINT N30CAPPCHFK4 ; 

ALTER TABLE N30TAPPCH ADD SOSDTTM DATETIME { suspense until datetime ) 

YEAR TO SECOND; 
ALTER TABLE N30TAPPCH ADD TOPLEAD CHAR(l) DEFAULT 'N' 

NOT NULL CHECK (TOPLEAD IN ('Y', 'N')); { Top Lead Flag ) 

Merchant Changes 

ALTER TABLE N30TAPPM ADD NTS TEXT; { Connnents 

ALTER TABLE N30TAPPM ADD CDSLSSTID INTEGER; { Sales Status } 

ALTER TT^LE N30TAPPM ADD CONSTRAINT 

FOREIGN KEY (CDSLSSTID) REFERENCES N30TCDSLSST (ID) CONSTRAINT N30CAPPMFK1; 

ALTER TABLE N30TAPPM ADD CDAGSTID INTEGER; { Agreement Status ) 

ALTER TABLE N3 0TAPPM ADD CONSTRAINT 

FOREIGN KEY (CDAGSTID) REFERENCES N30TCDAGST (ID) CONSTRAINT N30CAPPMPK2; 

ALTER TABLE N3 0TAPPM ADD CDASTRID INTEGER; { app Status Reason ) 

ALTER TABLE N30TAPPM ADD CONSTRAINT 

FOREIGN KEY (CDASTRID) REFERENCES N30TCDASTR (ID) CONSTRAINT N30CAPPMFK3; 

ALTER TABLE N30TAPPM ADD AGNUSRID INTEGER; ( agent systusr.id working } 

ALTER TABLE NSOTAPPM ADD CONSTRAINT 

FOREIGN KEY (AGNUSRID) REFERENCES SYSTUSR(ID) CONSTRAINT N30CAPPMFK4; 

ALTER TABLE N30TAPPM ADD SUSDTTM DATETIME { suspense until datetime ) 

YEAR TO SECOND; 
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AliTER TABLE N30TAPPM ADD TOPLEAD CHAR(1> DBFADLT 'N' 

NOT NULL CHECK (TOPLEAD IN ('Y', 'N')); {Top Lead Flag 

Table 48: Sales History 

CREATE TABLE N30TSAHIST 

ID INTEGER NOT NULL, 

AGNUSRID INTEGER NOT NULL, 
CALLDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
APPID INTEGER NOT NULL, 
CALLTIME INTEGER NOT NULL, 
CRTUSRID CHAR (15) NOT NULL, 
CRTDTI74 DATETIME 

YBTiR TO SECOND NOT NULL, 
CRTSRVR CHAR (IS) NOT NULL, 
CRTCLNT CHAR (15) NOT NULL, 
CHGUSRID CHAR (15) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CH6SRVR CHAR (15) NOT NULL, 
CH6CLNT CHAR (15) NOT NULL, 



PCT/USOl/04515 



45 



50 



55 



60 



65 



70 



( agents user Id } 

{ call date time 

( application id 
{ call time in seconds } 

{ create user id 
{ create date time 

{ create server 
{ create client 
{ change by user 
{ change date time 

{ change server 
{ change client 



PRIMARY KEY (ID) CC^STRAINT N30CSAHISTPK, 
FOREIGN KEY (AGNUSRID) REFERENCES SYSTUSR(ID) CONSTRAINT N30CSAHISTFK1 
) LOCK MODE ROW; 

INSERT INTO SYSTID (NM, LSTID) VALUES ( "N30TSAHIST" , 1000); 



Table 49: Sales Scripts 



CREATE TABLE N30TSASCRP 
( 

ID INTEGER NOT NULL, 
NM CHAR (30) NOT NULL, 
SCRP TEXT NOT NULL, 
CRTUSRID CHAR (15) NOT NULL, 
CRTDTTM DATETIME 



{ script id 
{ script name 
{ script 
{ create user id 
{ create date time 



{ id 
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YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (IS) NOT NULL, 
CHGUSRID CHAR (15) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NOLL, 
CHGSRVR CHAR (15) NOT NULL, 
CHGCLNT CHAR (15) NOT NULL, 



( create server } 

{ create client ) 

{ change by user ) 

{ change date time ) 

{ change server } 

{ change client } 



PRIMARY KEY (ID) CONSTRAINT N3 0CSASC31PFK 
) LOCK MODE ROW; 

INSERT INTO SYSTID (NM, LSTID) VALUES ( "N30TSASCRP" , 1000); 



Table SO: Script Relationsbips 



CREATE TABLE N30TSASCRFREL 



ID INTEGER NOT NULL , 

PSASCRPID INTEGER NOT NULL, 
CSASCRPID INTEGER NOT NULL, 



{ parent script id } 
{ child script id ) 



CRTUSRID CHARdS) NOT NULL, 
CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHARdS) NOT NULL, 
CRTCLNT CHARdS) NOT NULL, 
CHGUSRID CHARdS) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHARdS) NOT NULL, 
CHGC:LNT CHARdS) NOT NULL, 



{ create user id 

{ create date time 

{ create server 

{ create client 

{ change by user 

{ change date time 

{ change server 

{ change client 



PRIMARY KEY (ID) CONSTRAINT N30CSASCRPRELPK, 
FOREIGN KEY (PSASCRPID) REFERENCES N30TSASCRP (ID) CONSTRAINT N3 OCSASCRPRELFKl , 
FOREIGN KEY (CSASCRPID) REFERENCES N30TSASCRP (ID) CONSTRAINT N30CSASCRPRELFK2 
) LOCK MODE ROW; 

INSERT INTO SYSTID (NM, LSTID) VALUES ("N30TSASCRPREL" , 1000); 
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Table SI: 

CREATE TABLE N30TSAQ 
{ 

ID INTEGER MOT NULL, 
TYPE CHAR(l) NOT NOLL, 

} 

DESC CHAR (80) NOT NOLL, 
SQL CHAR (300) NOT NULL, 

} 

SASCRPID INTEGER, 

CRTUSRID CHAR (15) NOT NULL, 

CRTDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (15) NOT NOLL, 
CHGUSRID CHAR (15) NOT NULL, 
CHQDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 
CHGCLNT CHAR (15) NOT NULL, 



Agent Queue 



{ queue Id } 

{ 'M* Merchant, 'C Cardholder 

{ description J 

{ sgl statement 

{ script for this queue } 

{ create user id } 

{ create date time } 

{ create server ) 

{ create client } 

{ change by user } 

{ change date time } 

{ change server } 

{ change client ) 



PRIMARY KEY (ID) CONSTRAINT N30CSAQPK, 
FOREIGN KEY (SASCRPID) REFERENCES N3 OTSASCRP (ID) CONSTRAINT N30CSAQPK1, 
CHECK (TYPE IN ('M', 'C')) CONSTRAINT N30CSAQ1 
) LOCK MODE ROW; 

INSERT INTO SYSTID (NM, LSTID) VALUES ("N30TSAQ", 1000); 



Tabic 52: Sales Agent Assignment 



CREATE TABLE N30TSAASGN 



ID INTEGER NOT NULL. 

AGNUSRID INTEGER NOT NULL, 
SEQ INTEGER NOT NULL, 
SAQID INTEGER NOT NULL, 
CRTUSRID CHAR(15) NOT NULL, 
CRTDTTM DATETIME 



{ agent systusr.id 
{ sequence } 
{ queue id 

{ create user id 
( create date time 



I Id 
) 
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YEAR TO SECOND NOT NULL, 
CRTSRVR CHAR (15) NOT NULL, 
CRTCLNT CHAR (15) NOT NULL, 
CHGUSRID CHAR (15) NOT NULL, 
CHGDTTM DATETIME 

YEAR TO SECOND NOT NULL, 
CHGSRVR CHAR (15) NOT NULL, 
CHGCLNT CHAR (15) NOT NULL, 
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( create server ) 

{ create client } 

{ change by user ) 

{ change date time } 

{ change server } 

{ change client } 



PRIMARY KEY (ID) CONSTRAINT N30CSAASGNPK, ' 
UNIQUE (AGNUSRID, SEQ) CONSTRAINT N30CSAASGN1, 

FOKBIQIT KEY (AQNUSRID) REFERENCES SYSTUSR(ID) CONSTRAINT N30CSAASGNFK1, 
FORBIGil KEY(SAQID) REFERENCES N30TSAQ(ID) CONSTRAINT N30CSAAS6NFK2 
} LOCK MODE ROW; 

INSERT INTO SYSTIO (NM, LSTID) VALUES ("N30TSAASGN" , 1000} ; 

VIEW: Card Holder Apps Waiting TO be Processed 
Notes: Either IN SalesWaitiog status OR Suspended 
but suspense-until lias expired. 

CREATE VIEW N30VAFPCH1 
AS 

SELECT * 

FROM N30TAPPCH 

WHERE CDAST = 6 

OR (CDAST=8 AND SUSDTTM IS NOT NULL AND SUSDTTM < (CURRENT YEAR TO SECOND) ) ; 

VIEW: Merchant Apps Waiting 

CREATE VIEW N30VAPPM1 
AS 

SELECT * 
FROM N30TAPPM 
WHERE CDAST s 6 

OR (CDASTbS and SUSIXTTM IS NOT NULL AND SUSDTTM < (CURRENT YEAR TO SECOND) } ; 

MODIFY constraints ON cards TO allow multiple OF 
same card NUMBER AS LONG AS FOR diflerent dates 

ALTER TABLE N30TACCCHC DROP CONSTRAINT N30CACCCHC3; 

ALTER TABLE 1I30TACCCHC ADD CONSTRAINT UNIQUE (CNUM, EDT) CONSTRAINT N30CACCCHC3; 

ADD NEW card status FOR lost/stolen 
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INSERT INTO N30TCDCHCS (ID, DESC, AUTH) VALUES (30, 'IiOst/Stolen* , 'N'); 

VIEW: Merchant AppsDups 

CREATE VIEW N30VAPPM2 (ID) 
AS 

SELECT MAX (ID) 
FROM N30TAPPM 
WHERE COAST = 1 
GROUP BY CPNAM/ 

VIEW: Card Holder Apps Dups 

CREATE VIEW N30VAPPCH2 (ID) 
AS 

SELECT MAX (ID) 
PROM N30TAPPCH 
WHERE CDAST » 1 
CJROUP BY CPNAM; 

VIEW: East Time Zone Merchant Apps 

CREATE VIEW N30VAPPM3 
AS 

SELECT * 
FROM N30TAFPM 
WHERE CDAST » 6 

AND ST 
('ME' , 'NH' , 'VT' , 'NY» , 'PA' , 'WV» , 'VA* , ' OH' , ' MI • , ' IN' , 'NC , • SC , 'GA' , » FL • , 'NJ' , 'MA' , ' CT ' , 
»RI», 'MD», 'PR', 'ON* , "QB' , 'NB' , 'NS') ; 

VIEW: Central Time Zone Merchant Apps 

CREATE VIEW N30VAPPM4 
AS 

SELECT * 
FROM N30TAPPH 
WHERE CDAST « 6 

AND ST 
CND' , 'SD* , 'MN' , 'WI' , 'lA' , 'NE» , 'IL' , 'MS' , 'KS' , 'OK' , 'KY' , 'TN' , 'AL« , 'MS' , 'LA' , 'TX' , 'AR' ) 

VIEW: Mountain Time Zone Merchant Apps 

CREATE VIEW N30VAPPM5 



-69- 



wo 01/058242 PCTAJSO 1/045 15 

AS 

SELECT * 
PROM N30TAPPM 
WHERE CDAST = 6 

AND ST IN CMT' , 'ID' , 'WY', 'UT' , 'CO', 'AZ' , 'NM') ; 

VIEW: Pacific Time Zone Merchant Apps 

CREATE VIEW N30VAPPM6 
AS 

SELECT * 
FROM N30TAPPM 
WHERE CDAST » 6 

AND ST IN (»BC» , "WA* , »0R' , 'CA* , 'NV' , 'HI' , 'AK') f 

VIEW; East Time Zone Card Holder Apps 

CREATE VIEW N30VAPPCH3 
AS 

SELECT * 

FROM N30TAPPCH 

WHERE CDAST a 6 

AND ST 
( 'ME' , 'NH' , 'VT» , 'NY' , 'PA» , 'WV' , 'VA' , 'OH' , 'MI' , 'IN' , 'NC , 'SC , 'GA' , ' FL\ 'NJ' , 'MA' , 'CT» , ' 
»R1' , 'MD» , »PR' , 'ON' , »QB' , 'NB' , 'NSM ; 

VIEW: Central Time Zone Card Holder Apps 

CREATE VIEW N3 0VAPPCH4 
AS 

SELECT *' 

FROM N3 0TAPPCH 

WHERE CDAST b 6 

AND ST 
('ND' , 'SD' , 'MN' , »WI' , 'lA' , 'NBS ' IL' , 'MS ' , ' KS» , 'OK' , ' KY' , 'TN', 'AL', »MS», »LA' , 'TX', »AR') ; 

VIEW: Mountain Time Zone Cardholder Apps 

CREATE VIEW N30VAPPCH5 
AS 

SELECT ♦ 

VRCm N30TAPPCH 

WHERE CDAST = 6 
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AND ST IN CMT' , 'ID' , 'WY' , 'in" , 'COS 'AZ' , 'NM') ; 

VIEW: Pacific Time Zone Card Holder Apps 

CREATE VIEW N30VAPPCH6 
AS 

SELECT * 

FROM N30TAPPCH 

WHERE CDAST = 6 

AND ST IN ('BC'.'WA','OR','CA\ W,'HI»,'AK'); 

Table 53: N30TB1>GXR£F 

CREATE TABLE N30TBDGXREF 
( 

ID INTEGER NOT NULL , 

ACCCHCID INTEGER NOT NULL , 

BDGID CHAR (SO) NOT NULL , 

CRTUSRID CHAR (IS) NOT NULL , 

CRTDTTM DATETIME YEAR TO SECOND NOT NULL , 

CRTSRVR CHAR{XS) NOT NULL , 

CRTCLNT CHAR (15} NOT NULL , 

CHOUSRID CHAR (15) NOT NULL , 

CHGDTTM DATETIME YEAR TO SECOND NOT NULL , 

CHGSRVR CHAR (15) NOT NULL , 

CHGCLNT CHAR (15) NOT NULL , 

UNIQUE (BDGID) CONSTRAINT "INFORMIX" .N30CBDGXREF1, 
PRIMARY KEY (ID) CONSTRAINT "INFORMIX" .N30CBDGXREFPK 
) LOCK MODE ROW; 
ALTER TABLE N30TBDGXREP ADD ACCID INTEGER NOT NULL; 

ALTER TABLE N30TBDGXREF ADD EXPDT DATE; 
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WHAT IS CLAIMED IS : 

1 . A method of conducting electronic commerce, the method comprising: 
receiving an electronic authorization request from a vendor for a payment 

guarantee^ v^herein the authorization request identifies a transaction amount between the 
5 vendor and a buyer; and 

electronically transmitting to the vendor a guarantee of payment for the transaction 
amount, wherein the guarantee is conditional to the occurrence of one or more events. 

2. The method of Claim 1, wherein one of the events is receipt of an invoice from the 

vendor. 

10 3. The method of Claim 1, comprising charging the vendor a transaction fee 

regardless of the occurrence of the conditions. 

4. The method of Claim 3, wherein the transaction fee is based at least in part upon 
either the transaction fee or a payment due date. 

5. The method of Claim 1, additionally comprising: 

15 receiving an invoice from the seller, wherein the invoice identifies an actual 

transaction amount of a transaction between the buyer and the seller; and 
storing the actual transaction amount in a database. 

6. The method of Claim 1, additionally comprising transmitting the invoice to a 
guarantor. 

20 7. The method of Claim 1, additionally comprising determining whether to guarantee 

payment 

8. The method of Claim 1, wherem determining whether to guarantee payment is 
based at least m part upon a credit limit of the buyer. 

9. The method of Claim 1, additionally comprising: 

25 receiving an invoice from the seller, wherein the invoice identifies a payment due 

date; and 

determining, based at least in part upon the due date, a fee that is due by the seller, 

10. The method of Claim 9, additionally comprising: 
receiving payment from the buyer; and 

30 sending payment to the vendor subsequent to subtracting the determined fee. 

11. The method of Claim 1, wherein the guaranteeing payment comprises insuring 
payment by the seller. 

12. The method of Claim 1, wherein guaranteeing payment comprises purchasing a 
receivable from the vendor. 

35 
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13. A system for conducting electronic commerce, the system comprising: 

means for receiving an electronic authorization request from a vendor for a 
payment guarantee, wherein the authorization request identifies a transaction amount 
between the vendor and a buyer; and 
5 means for electronically transmitting to the vendor a guarantee of payment for the 

transaction amount, wherein the guarantee is conditional to the occurrence of one or more 
events. 

14. The system of Claim 13, wherein one of the events is receipt of an invoice from 
the vendor. 

10 15. The system of Claim 13, comprising means for charging the vendor a transaction 

fee regardless of the occurrence of the conditions. 

16. The system of Claim 15, wherein the transaction fee is based at least in part upon 
either the transaction fee or a payment due date. 

17. The system of Claim 13, additionally comprising: 

15 means for receiving an mvoice from the seller, wherein the invoice identifies an 

actual transaction amount of a transaction between tlie buyer and the seller; and 
means for storing the actual transaction amount in a database. 

18. Tiie system of Claim 13, additionally comprising means for transmitting the 
invoice to a guarantor. 

20 19. The system of Claim 13, additionally comprising means for determining' whether 

to guarantee payment. 

20. The method of Claim 13, wherein the means for determining whether to guarantee 
payment reads a credit limit of the buyer from a database. 

21 . The system of Claim 13, additionally comprising: 

25 means for receiving an invoice from the seller, wherein the invoice identifies a 

payment due date; and 

means for determining, based at least in part upon the due date, a fee that is due by 
the seller. 

22. The system of Claim 21, additionally comprismg: 
30 means for receiving payment from the buyer; and 

means for sending payment to the vendor subsequent to subtracting the determined 

fee. 

23. The system of Claim 13, wherein the means for guaranteeing payment issues an 
insurance policy on the transaction. 
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24. The system of Claim 13, wherein the means for guaranteeing payment purchases a 
receivable from the vendor. 
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Approval Screen 



a ^ 4= 



Back Forward Reload Home Search Guide Images Print Print Print 



N 



Netsite: 




ProfitScape 



GUARANTEE YOUR 
RECEIVABLES 



ENTER YOUR USER ID 



ENTER PASSWORD 



© ((enter) 



RETAIL WEB 
STORES 



WHOLESALE WEB 
STORES 



UST 

ALPHABETICALLY 



YOUR COMPANY INTERNATIONAL 

25448 Costonza Blvd. Suite 800 
Chicago, IL 65330 



Enter Card Number, Expiration date and Amount below tlien "VERIFY" 

Net30 Card Number Expirqtten Dote Amount Purchoae Order (optionol) 

16526-7166-91701 106/2005 I |$4300.00 I |P0 8996492 | 



Comjjony 



Card Number 



Amount 



PO # 



PHILLYBUSTER DESIGNS 
167 Darth Drive 
Wollawaila WA 38115 

JACKSON-HILL 
9534 Blister Ave. 
Wallcwalla WA 55143 

GRAVITON SYSTEMS 
4441 Beanleprop Blvd. 
WallQwallo AL 57662 

SUZIE'S BOUTIQUE 
5813 Mall Ridge 
Waltawallo AZ 38115 



PS6526-7166-9170 
exp. 06/2003 



$4,300.00 



8996492 



ps 9926-5846-3496 $6,766.00 
e;q). 08/2002 



PS 9354- 3352-1774 $12,800.00 
exp. 12/2003 



0> 



44131 



PS 6526-7166-9170 
exp. 06/2003 



$ 500.00 




When finished click on "Please Approve" for Approval codes 

on the selected orders above V^ yPPROVE^ 



To edit records enter 



Company Name \ 



or Approval Code PS743S5 



t SEARCH 



^ I http: //13S. 145. 16.61; SO/morket A'<<ex-htm 
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Bock Forward Reload Home Search Guide Images Print Print Print 


N 


^ Netsite: 1^ | 


I \ ProfitScape 


GUARANTEE YOUR 
RECEIVABLES 

ENTER YOUR USER ID 




YOUR COMPANY INTERNATIONAL 

25448 Costanzo Blvd. Suite 800 
Chicogo, IL 65330 


ENTER PASSWORD 




EDIT TRANSACTION RECORD 




Company Amount Approval Code 


(CENTER)) 

RETAIL WEB 
STORES 

WHOLESALE WEB 
STORES 

LIST 

ALPHABETICALLY 




PHILLYBUSTER DESIGNS $ 4,400.00 Approved - PS74355 
167 Darth Drive 
Wallawolla WA 38115 

JACKSON- HILL $ 6,766.00 Approved - PS64288 
9534 Blister Ave. 
Wallawafia WA 55143 

GRAVITON SYSTEMS $12,800.00 DENIED - Over credit limit 
4441 Beanieprop Blvd. 
Wallowalla WA 57662 

SUZIE'S BOUTIQUE % 500.00 Approved - PS11298 
5813 Mall Ridge 
Wallawallo WA 38115 




^ http://135. 145.16.61: 80/market/indexhtm | //^ 
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Back Forward Reload Home Search Guide Images Print Print Print 



N 



Netslte; 




ProfitScape 



GUARANTEE YOUR 
RECEIVABLES 



ENTER YOUR USER ID 



ENTER PASSWORD 



RETAIL WEB 
STORES 



WHOLESALE WEB 
STORES 



LIST 

ALPHABETICALLY 



YOUR COMPANY INTERNATIONAL 

25448 Costonza Blvd. Suite 800 
Chicago, IL 65330 



EDIT TRANSACTION RECORD 



Company 



Card Number 



Amount 



P0# 



PHILLYBUSTER DESIGNS |PS 6526-7166- 9 170 1 | $2500.00 

157 Oarth Drive | , 

Wallawalla WA 38115 |exp. 06/2003 



8996492 



When finished click on "Recalculate Approval" for 
New Approval Code. 

Previous Approval Code will no longer be valid* 
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DECLARATION OF NON-ESTABLISHMENT OF INTERNATIONAL SEARCH REPORT 
(PCT Article 17(2){a). Rules 1 3ter.1 (c) and Rule 39) 



Applicant's or agenf s file reference 
PSCAPE.004VP 


IMPORTANT DECLARATION 


Date of mm\mg(day/month/year) 

11/06/2001 


International application No. 

PCT/ US 01/04515 


International filing da\Q(day/month/year) 

12/02/2001 


(Earliest) Priority date (day/month/year) 
11/02/2000 


Interrwtional Patent Classification (IPC) or both national classification and IPC G0SF17/60 


Applicant 

PR0FITSCAPE.COM, INC. et al. 



This International Searching Authority hereby declares, according to Article 17(2)(a), that no internatfonal search report will 
be established on the international application for the reasons indicated below 

1 • [X] The subject matter of the international application relates to: 

a. I ] scientific theories. 

b. Q nnathematical theories 

c. I 1 plant varieties. 

d. Q animal varieties. 

e. rn essentially biological processes for the production of plants and animals, other than microbiological processes 
— and the products of such processes. 

f . ^schemes, rules or methods of doing business. 

g. Q schemes, lules or methods of perfomiing purely mental acts. 

h. Q schemes, mles or methods of playing games. 

I. Q methods for treatment of the human body by surgery or therapy, 

j. Q] methods for treatment of the animal body by surgery or therapy, 

k, Q diagnostic methods practised on the human or animal body. 

I. Q] mere presentations of infomnation. 

m. □ computer programs for which this International Searching Authority Is not equipped to search prior art 

2. rn The failure of the following parts of the International application to comply with prescribed requirements prevents a 

— meaningful search from being carried out: 

Q the description Q the claims Q the drawings 

3. rn The failure of the nucleotide and/or amino acid sequence listing to comply with the standard provided for In Annex C of the 

— Administrative Instructions prevents a meaningful search from being carried out: 

I I the written forni has not been furnished or does not comply with the standard. 

Q the computer readable form has not been furnished or does not comply with the standard. 

4. Further comments: 



Name and mailing address of the international Searching Authority 

European Patent Office, P.B. 5818 Palentlaan 2 

NL-2280 HV Rljswljk 

Tel. (+31-70) 340-2040. Tx. 31 651 epo nl. 
Fax: (+31-70) 340-3016 



Authorized officer 

Mar 'a Rodr'guez Novoa 



Form PCT/ISA/203 (July 1998) 



international Application No. PCT/US 01/04515 



FURTHER INFORMATION CONTINUED FROM PCT/ISA/ 203 



The subject-matter claimed in claims 1-12 falls under the provisions of 
Article 17(2) (a) (i) and Rule 39.1(iii), PCT. such subject-matter relating 
to a method of doing business. 

Claims 13-24 relate to a conventional system (program product, computer 
readable medium) for performing the business method of claims 1-12. 
Although these claims do not literally belong to the method category, 
they essentially claim protection for the same commercial effect as the 
method claims. The International Searching Authority considers that 
searching this subject-matter would serve no useful purpose. It is not at 
present apparent how the subject-matter of the present claims may be 
considered defensible in any subsequent examination phase in front of the 
EPO as International Preliminary Examining Authority with regard to the 
provisions of Article 33(1) PCT (novelty, inventive step); see also 
Guidelines B-VII. 1-6). 

The applicant's attention is drawn to the fact that claims relating to 
inventions in respect of which no international search report has been 
established need not be the subject of an international preliminary 
examination (Rule 66.1(e) PCT). The applicant is advised that the EPO 
policy when acting as an International Preliminary Examining Authority is 
normally not to carry out a preliminary examination on matter which has 
not been searched. This is the case irrespective of whether or not the 
claims are amended following receipt of the search report or during any 
Chapter II procedure. If the application proceeds into the regional phase 
before the EPO, the applicant is reminded that a search may be earned 
out during examination before the EPO (see EPO Guideline C-VI. 8.5), 
should the problems which led to the Article 17(2) declaration be 
overcome. 
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